Bar coded bill payment system and method

ABSTRACT

A financial transaction involving a bar coded invoice and validating the bar code to limit carrying out of the financial transaction to a first type of financial transaction, where the bar code has discrete encoded data fields organized into validation levels, including an outer level and an inner levels, the encoded data fields include a field designator, a check digit value and/or a data string, the data string includes either an inner validation level and/or payment information, the payment information includes the identity of the payee and the payer, where the encoded data fields are established pursuant to a decoding method, a validation method and a processing method, where decoding includes decoding the bar code to yield a series of data values, validation includes determining whether the bar code corresponds to a first type of financial transaction, and processing includes processing the financial transaction to pay the third party payee.

CORRESPONDING PATENT APPLICATIONS

The present application is a continuation of U.S. Ser. No. 12/371,547filed Feb. 13, 2009, which is a continuation of U.S. Ser. No. 10/020,691filed Dec. 14, 2001, which is a continuation-in-part of U.S. Ser. No.09/737,011 filed Dec. 14, 2000, all of which are expressly incorporatedby reference herein.

BACKGROUND

The present invention relates to a system and method for performingfinancial transactions, and more particularly, to a payment system andmethod using bar code identification.

Traditional Bill Payment Paradigm

The current paradigm of the bill payment cycle for goods and servicesrendered has improved only in incremental steps since the beginning oftime. In ancient times, most goods and services were exchanged betweenindividuals, using the common currency of the realm or by a mutuallyagreed upon barter arrangement. Extension of credit for goods andservices was generally limited to the affluent and wealthy. When paymentwas due, handwritten invoices were hand delivered. Sometime later, cashpayment would be remitted in person. Most trade occurred at the locallevel between individuals, exchanging cash or barter goods.

In the late 1800's and early 1900's in the United States, credit forgoods and services rendered remained essentially unchanged at the locallevel. Society became less stratified and there became an affluentmiddle class populace between the highest and lowest levels of society.Credit for goods and services became extended to select groups andindividuals within this populace as well as the affluent and wealthy.However, invoices were still handwritten tallies of goods and servicesrendered, which were paid for in cash. The Industrial Revolutionprecipitated many technology advances in transportation andcommunication, which affected many facets of daily life. In commerce,the foundation cornerstones of the financial services industry, as itexists today, were developed and shaped. With an infrastructure of anational mail network and a solid central banking system in place, themore affluent and wealthy individuals began to have a larger and moreconvenient span of financial control with extended remote banking creditservices. Merchants could then send their invoices to distant customersthrough the national mail network and receive payments, sometime later,in the form of a bank draft honored by the local bank for cash.

In the generations following World War II to the present time, withgeneral society becoming more and more homogenized and, on the wholemore affluent, banking services are available and competitive at everylevel. Bank checking accounts (and therefore a credit mechanism withwhich to pay remote billers) are available to 60 percent or more of thepopulation. The national mail network is a very cost-effective deliverysystem for local and remote customers of automated or machine printedmonthly invoice statements, which average 15.9 billion annually.Customers write checks, as payment for these invoices, and return themvia the mail network. When received at the merchant directed returnlocation (a bill payment-processing center), these mail payments areopened, the checks deposited, and the customer accounts credited withthe face amount of these check payments.

If everyone were to pay their bills on or before the due date with validchecks, this state of the bill payment industry might be sufficient tosatisfy most of today's societal needs. However, this is not the case.Some people never pay their bills on time, for a variety of reasons.Payments made with a check are not always covered with sufficient fundsat their bank. The end result consequence to the biller is a finite costthat is directly attributable to the disruption of the flow of goods andservices through his business.

To cover the costs incurred by these late payments, billers have onlytwo options available to them. One option is to spread this overheadcost over of all the goods and services that they provide, with thepossible consequence of pricing their products or services out of thecompetitive price range for similar or substitute set of products andservices. The second option is to impose payment penalties on thosecustomers who pay late—for whatever reason. This second option isgenerally more preferable since it targets the problem populationsegment directly. However, billers are often unable to recover the fullcost of late payment consequences from those customers and still staywithin the public legal and regulatory mandates.

Recently, there have been business attempts to further automate the billpayment process by the electronic delivery of biller invoices and thesubsequent electronic remittance of payments. While the electronicpresentment of bill payments might address the current 15% or so of theU.S. population with access to the Internet, it does not address the 85%without Internet access. Within the next decade, the Internet wiredsegment of the population will not grow as fast as the current crop of“dot com” entrepreneurs hope or project in their “new” economy businessplans. The latest statistics show that less than 3% of the Americanpublic may use on-line remittance services.

Federal statistics indicate that fully 30-40% of the U.S. population maybe “unbanked”. The “unbanked” population operates solely within the casheconomy without any formal banking level traceability. There are manyreasons that people prefer to operate in this economy, some of which areculturally related. Others prefer anonymity for quite specific reasons,such as illegal aliens avoiding detection and deportation by the INS orothers hiding their sources of income from the IRS. Federal statisticsalso indicate that 30-40% of the adult U.S. population may have aworking fourth grade education or less.

There may be a correlation between those people opting for the casheconomy and the fact that many may not be able to maintain and balance acheckbook. Most people would rather admit to being “unbanked” ratherthan to being illiterate. The “unbanked” segment of the population hasdifficulty operating in a check-oriented society and paying theirmonthly bills to remote billers. At the local level, theproprietor-operated check cashing storefronts may service some of theneeds of these individuals. Weekly paychecks are cashed for atransaction charge (mostly based on the face value of the check), andmoney orders are then bought, to be enclosed with mailed bill payments.When bill payments are long past their due date, these individuals mayhave to resort to more expensive electronic wire services to avoidservice disconnects.

For the great majority of printed bill payment invoices that aredistributed every month, each biller automates and optimizes its billcollection and remittance process to suit the requirements of itsinstalled paper handling equipment and flavor of customer accountnumbering assignments and schemes. Bill remittance stub sizes andformats vary from postcards printed with dot matrix printers tofull-page 8½″ by 11″ sheets with laser printed invoice information onpreprinted forms. Each has a tear-off bill remittance stub portion thatis then mailed back with a check payment. Account numbers on these billremittance stubs appear in different (and sometime multiple) spatialpositions, formats and fonts. While still not universal, most billershave formatted their account numbers (and other customer relatedinformation) on bill remittance stubs in Optical Character Recognition(OCR) readable scan lines. Some of this information is printed twice onthe bill remittance stub as a contingency that the paper bill remittancestub is shredded or mangled by the automation equipment. Human dataentry of this customer account number information is the ultimatefallback mode for processing this payment.

Traditional Bill Payment Examples

FIG. 1 shows an exemplary local gas company remittance stub 100utilizing this manner of design. The biller in this example has assigneda numeric account number to each of his customers. As shown in FIG. 1,the customer account number is printed three times, the human readableone 102 under the “Your Account Number” heading, and the other two 103,104 printed twice in machine-readable form. Account number check digits101 are used to validate the account number. Each digit in the accountnumber is multiplied by a mathematical weight, and then all theseproducts are added together. Dividing the total sum by 10 andcomplementing the remainder yields the check digit that is comparedagainst the indicated digit. If the digits match, then the accountnumber has been detected and read correctly. Check digits are employedto eliminate two types of common errors, physical digit read errors andtransposition errors (when the customer account number is processedmanually).

FIG. 2 shows an exemplary remittance stub 200 from a local power companythat assigns a combination of letters and digits to its customer base.There are two forms of the customer account number 201 that appear onthe bill remittance stub. The first 201 is designed to be human readablebecause it appears within a printed text box labeled “Account Number”.The last digit in the Account Number box is the customer account numbercheck digit. The second form of the customer account number 202 appearsin machine-readable form and is embedded in the OCR scan line(underlined for illustration). The leading “4” digit is the customeraccount number check digit and the remainder of the underlined portionof the OCR line are the digits that can be mapped into the humanreadable “Account Number” form. The format of this machine-readable OCRscan line 202 is probably a confluence of many internal designdecisions, based on several factors. From a human ergonomicsperspective, a customer service representative of the power company,during a service call, would never ask a customer to recite his accountnumber from a sequence of digits appearing within the machine-readableOCR line and expect a correct answer. The human readable form 201 of thecustomer account number is easier for a customer to recognize and todictate over the telephone when requesting service changes to hisaccount.

These two examples illustrate the primary uses of duplicate accountinformation printed on a bill remittance stub—one for simplicity whenverbally referring to a specific customer account and the second for thecase that the automation process fails and customer account numberpayment information has to be entered manually.

FIG. 3 shows an exemplary remittance stub 300 from a gas company, inwhich the biller automates part of the bill payment remittance processby including, on the bill remittance stub, company proprietary bar codedinformation 301 that does not appear to be related in any way to theprinted customer account number. While the format of this billremittance stub 300 may marginally advance that biller'sstate-of-the-art bill collection and system processing with the use ofnewer and improved automation equipment, it does not significantlydecrease, in favor of the customer, the overall bill payment cycle. Thegreat majority of the bill payment cycle time consists ofnon-deterministic time delays in the national mail network during thebiller-to-customer and the payment-to-biller delivery paths. Theserandom time delays, combined with very short biller dictated due datesand (possibly intentional) delayed processing times, always work to thedetriment of the customer. As a result, some customers are assessedpenalty payments, which are sometimes more profitable than the basicgoods and services provided.

The system of bill payment invoicing, collection and remittanceprocessing remains a fragmented industry because there are no commonbill remittance stub format standards, no common customer account numberrepresentation standards, no common, expedient data and money deliverymechanisms to the biller, and no large bill remittance stub processingnetworks, in addition to payment cycle delays that always work to thedetriment of the customer to favor the biller (with a correspondinglygreater profit margin). By constructing a common set of standards fromthe current set of available technology components, a universal nationalbill payment network could be implemented that addresses the above listof industry problems, resulting in a positive economic impact to thebusiness community at large. For such a set of standards to work, thecooperation of several large organizations would be required; howeverincreases in raw profit and new business growth opportunities shouldinduce such cooperation.

As shown in FIG. 4, a system 400 consistent with the existing billpayment paradigm uses the national mail network and biller paymentprocessing centers to convert physical paper into electronic data andbank credits. The current bill payment network is a paper based networkthat primarily relies on the central banking system for processingcustomer remitted bank draft payments and the national mail network forcustomer invoice delivery and the return of mailed bill payments. Insystem 400, for all the goods and services rendered to a customer over agiven billing period, the biller accounts receivable 40 I accumulates adollar total and generates a detailed machine printed invoice (which maytake 4-5 days after account cut-off time to process) that is sent to thecustomer 403 via U.S. Mail 402. The customer (i.e. payee) 403 typicallyreceives the invoice 2-3 days later (which time is variable, without anydirect traceability from the perspective of either the biller or thecustomer).

Once the customer receives the invoice in the mail, the customer makesout a check payments or procures a money order 404 to remit with a mailpayments which occurs sometime later, depending on the availability ofcash resources and other circumstances. The customer mails the paymentsvia U.S. Mail 405 to the biller collection and processing center 406,where processing time may be 2-3 business days or more (which time isvariable, without any direct traceability from the perspective of eitherthe biller or the customer). At the bill payment processing center 406,the following operations are typically performed: opening all receivedmail; microfilming and/or otherwise recording all received paymentselectronically reading and processing OCR bill remittance stubinformation; preparing all received check or money order payments forbank submission; and electronically remitting bill payment data, basedon check payment verification. Processing time within the processingcenter 406 may be 2-3 days.

It should be noted that there may be sanctioned late payment penaltiesimposed on credit card payments wherein a biller might gain an advantageby intentionally delaying an on-time payment by a day or so, therebycausing an otherwise on-time payment to be considered late. For example,for a $200 payment delayed by only one day, a $25 late payment penaltymight result in an equivalent Annual Percentage Rate (APR) interest rateof 150%, for little or no marginal cost to the biller. This overcharge,which may be difficult for the customer to trace later, may becompounded by another finance charge for the outstanding unpaid balanceamount, made late by that intentional delay.

Payment data is next remitted electronically from the processing center406 to the biller's bank 408, and processing and distribution ofelectronic payment data is typically done using the Federal ReserveAutomated Clearing House (ACH) Network 407, which typically takes 6-9hours. At the biller's bank 408, the electronic payment data is receivedfrom the ACH Network, stripped and reformatted according to billerspecified formats, which may take 4-6 hours. Finally, the biller'saccounts receivable 401 and/or customer service computer files areupdated. Depending on the “legacy factor” of the biller's computerprocessing systems, this process can range anywhere from 2-3 hours to4-5 days.

Assuming zero latency on the part of the customer paying his bill, thecycle time between the customer account cut-off time and the time thatthe customer payment is applied to his account, using the above timeestimates, may range from 13-18 days. Since there is usually somecustomer delay, the observed bill payment cycle time will be longer.

SUMMARY

In one embodiment of the present invention, a method is provided ofprocessing a financial transaction from a second party payer to a thirdparty payee at a point of sale location of a first party retailer, wherethe method comprises the third party payee creating a bar codecomprising discrete encoded data fields organized into a plurality ofvalidation levels comprising an outer validation level and one or moreinner validation levels, where each of the discrete encoded data fieldscomprising one or more of either a field designator, a check digit valueand/or a data string, the data string comprising either an innervalidation level and/or payment information, the payment informationcomprising the identity of the payee and the identity of the payer, andwhere the encoded data fields configured to be interpreted pursuant to adesign scheme comprising a decoding method, a validation method and aprocessing method, (i) the decoding method comprising decoding the barcode to yield a series of data values for use in the validation methodand the processing method, (ii) the validation method comprisingdetermining whether the bar code corresponds to a first type offinancial transaction as opposed to a second type of financialtransaction that cannot be processed, and (iii) the processing methodcomprising processing the financial transaction to pay the third partypayee. Embodiments of the method further comprise the second partybringing an invoice having the third-party-created bar code thereon tothe first party retailer; scanning the bar code and detecting thediscrete encoded data fields and validation levels; decoding thediscrete encoded data fields and validation levels yielding a series ofdata values used in applying the design scheme, validating the bar codeto limit the carrying out of the financial transaction to the first typeof financial transaction that can be processed pursuant to the designscheme, validating the bar code comprising, with respect to each of theone or more inner validation levels: (i) confirming that any formatdesignator and/or check digit value within the data string of the innervalidation level conforms to the design scheme, (ii) rejecting the barcode as being associated with the second type of financial transactionif any format designator and/or check digit value within the data stringdoes not conform to the design scheme, (iii) identifying any such datastring that does represent an inner validation level, and repeatingsteps (i), (ii) and (iii) for each such inner validation level; andprocessing the bar code of the first type of financial transaction,processing comprising (i) identifying each data string that does notrepresent an inner validation level and identifying the data valuestherein used in carrying out the financial transaction, (ii) the secondparty payer paying an agreed-upon amount of funds to the first partyretailer at the point of sale location; and (iii) directing a transferof funds from the first party retailer to the third party payee.

In some embodiments, the methods may further comprise the first partyretailer providing a receipt to the second party payer to document thetransaction by identifying details of the financial transaction. Themethods may also or alternatively further comprise alerting the thirdparty payee that the funds will be or have been transferred.

In some embodiments, the first type of financial transaction correspondsto a plurality of sets of bar codes in which each set of bar codescomprises a distinct design scheme. In some embodiments, the invoice maycomprise a digital image transmitted electronically. In someembodiments, the agreed-upon amount of funds paid are the same as theamount of funds transferred from the first party retailer to the thirdparty payee. In some embodiments, validating and decoding take place atthe same time.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is an exemplary prior art remittance stub from a utility company;

FIG. 2 is another exemplary prior art remittance stub from a utilitycompany;

FIG. 3 is another exemplary prior art remittance stub from a utilitycompany;

FIG. 4 is a process flow diagram of an exemplary prior art bill paymentsystem;

FIG. 5 is a process flow diagram of an exemplary bill payment systemconsistent with the present invention;

FIG. 6 is an illustration of an exemplary data structure of elementsunderlying the bar code “signature” in one embodiment of the presentinvention;

FIG. 7 is an illustration of another exemplary data structure ofelements underlying the bar code “signature” in one embodiment of thepresent invention;

FIG. 8 is an illustration of an exemplary bar code bill payment“signature” in one embodiment of the present invention;

FIG. 9 is a table illustrating the results of an exemplary split modulusmatching calculation in one embodiment of the present invention;

FIGS. 10 and 11 are illustrations of an exemplary Level 3 envelope inone embodiment of the present invention;

FIGS. 12 and 13 are process flow interaction diagrams of the mainlinetransaction information interchange between the checkout scanner,retailer host processor, and data collection network interface (DCNI)unit in processing a bar coded customer bill remittance stub, in oneembodiment of the invention;

FIG. 14 is a system view diagram of a transaction collection system inone embodiment of the present invention;

FIG. 15 is an exemplary transaction processor executive controller(TPEC) display screen, in one embodiment of the invention;

FIG. 16 is an exemplary system monitor station (SMS) display screen, inone embodiment of the invention;

FIG. 17 is an exemplary end of batch monitor (EBM) display screen, inone embodiment of the invention;

FIG. 18 is an exemplary electronic transmission interface (ETI) displayscreen, in one embodiment of the invention;

FIG. 19 IS an exemplary ETI transaction detail display screen, III oneembodiment of the invention;

FIG. 20 is an exemplary ETI map biller-to-partner display screen, IIIone embodiment of the invention;

FIG. 21 is an exemplary transaction browser display, in one embodimentof the invention;

FIG. 22 is a process flow diagram of another exemplary bill paymentsystem consistent with the present invention;

FIG. 23 is an illustration of an exemplary Level 3 envelope in oneembodiment of the present invention;

FIG. 24 is an exemplary bar coded deposit slip in one embodiment of thepresent invention;

FIG. 25 is an illustration of an exemplary gas station/convenience storedebit card known in the art; and

FIG. 26 is an illustration of an exemplary gas station/convenience storedebit card in one embodiment of the present invention.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS Biller-Payor Embodiments

Turning now to FIG. 5, a bar coded bill payment based system 500consistent with the present invention utilizes a bar code on the billerinvoice, which is then delivered to the customer via mail, and paymentinformation and payment credits are returned to the billerelectronically. Advantageously, nationally recognized and federallysanctioned payment electronic networks may be utilized for remittingcustomer payment data and funds. For all the goods and services renderedto a customer over a given billing period, the biller's accountsreceivable 501 accumulates a dollar total and generates a detailedmachine printed invoice including a special bar code, which is mailed tothe customer 503 via U.S. Mail 502. Time for processing and mailing maybe 4-5 days after account cut-off time, and the mail transit time to thecustomer may add an additional 2-3 business days or more before thecustomer receives the invoice (which time is variable, without anydirect traceability from the perspective of either the biller or thecustomer). The customer 503 then receives the invoice in the mail.Sometime later when cash resources are available, or depending on otherfactors, the customer 503 decides to pay bill. The time for this tooccur is variable, depending upon the customer's circumstances.

To pay the bill, the customer 503 takes the bar-coded invoice to aparticipating store (e.g. a supermarket) that processes bill payments.The customer presents his bar coded bill remittance stub to the checkoutcashier for scanning at the checkout scanner 504, which may be donewhile paying for other UPC-coded items. Instead of looking up anin-house UPC code for pricing, the scanner 504 picks up the bill paymentbar code that identifies the biller to be paid and the account number tobe credited. The customer informs the checkout cashier the amount to bepaid on that account, payment is tendered to the cashier, and thecashier inputs the amount to be paid into a terminal which is incommunication with a backend host processing system 505. Upon receivingpayment from the customer, that bill payment is then complete. The checkout of any remaining products and items (or bills) continues until thecomplete total for all goods and services is calculated. The customermay receive a printed receipt of the payment tendered with date and timethat the payment was made. The backend host processing system 505forwards all the payment data to the data collection network interface506 (“DCNI”). The processing time for all of the payment steps may be aslittle as a few seconds. Moreover, payments made in this manner aretime-stamped, so that once payment is made, the customer may restassured that payment has been timely acknowledged.

The data collection network interface 506 collects and stores all thecustomer payment data in non-volatile memory. Periodically throughoutthe day (based on time and transaction volume thresholds), or at otherpredetermined intervals, the interface 506 transmits the payment data tothe central site transaction collection system 507. Additionaltransmissions may be scheduled before the daily transaction collectionsystem 507 aggregation times. The time for the back-end and collectionsystem processing has no impact on customer payment time, since allpayments may be time-stamped. Separately calculated calendar day paymentcounts and totals may also be sent to the transaction collection system507 as an independent transaction audit balancing mechanism. Thetransaction collection system 507 may continuously receive payment datainformation from a distributed network comprising a plurality of datacollection network interface units 506 deployed at field retailestablishments. Before the last processing window closes at the FederalReserve Automated Clearing House (ACH) Network 508, all customerpayments are sorted and aggregated for direct remission to theirrespective billers, which may take approximately an hour. Processing anddistribution of electronic payment data is done using the FederalReserve Automated Clearing House (ACH) Network 508, which may take 6-9hours. At the biller's bank 509, the electronic payment data is receivedfrom the ACH Network, stripped and reformatted according to billerspecified formats, which may take 4-6 hours. Finally, the biller'saccounts receivable 501 and/or customer service computer files areupdated. Depending on the “legacy factor” of the biller's computerprocessing systems, this process can range anywhere from 2-3 hours to4-5 days.

Assuming zero latency on the part of the customer paying his bill, thecycle time between the customer account cut-off time and the time thatthe customer payment is applied to his account, using the above timeestimates, may range from 9-12 days (in contrast to the 13-18 days ofthe prior art system). Since there is usually some customer delay, theobserved bill payment cycle time will be longer.

Moreover, if the biller recognized the customer payment date and time asthe creditor date of receipt as specified in the Federal ReserveRegulation Z, Section 226.10, then the total bill payment cycle timewould be reduced to 6-8 days. Explicit agreement from the biller wouldbe secured through the biller registration process. The biller mayvalidate the customer payment date with the transaction embedded“electronic postmark”, which cannot be performed within the currentframeworks of either the paper based bill payment or the electronicpayment paradigms, today.

In addition to the more than 55% time reduction in the bill paymentcycle, other advantages of the present invention include: customerchoice of local bill payment locations, electronic application of billpayments to account within 24-36 hours, a reduction in bill paymenterrors with machine-readable bar coded account numbers, and timestamping of bill payments at the time payment is tendered.Electronically delivered bill payments, under the present invention, aremuch cheaper for the customer to pay for and less expensive for thebiller to process through its remittance processing center and accountsreceivable systems than under a prior art system. Additionally, banksthat process data from the ACH system will have more chargeable servicesto offer their biller customers. Furthermore, billers can incorporatethis bar coding standard into their bill remittance processing centers,as older OCR recognition equipment is replaced with simpler and morereliable laser bar code scanning equipment. With sufficient planning, abiller, contemplating a conversion of one or more legacy customeraccount numbering systems to a simpler, newer scheme, can use thissystem of bar coding in its conversion process. In an alternativeembodiment, electronic invoice delivery, whereby the customer receivesand prints the bar-coded invoice at his own computer system, may be usedto reduce the time and labor required for the biller to prepare and mailinvoices to the customer.

It is further contemplated that billers would register with acentralized organization in order to receive an assigned biller barcode, just as all companies must register with the Uniform Code Council(VCC) to get their Universal Product Code (UPC) assignment for theirproducts.

It should be understood that the foregoing described embodiment whichuses the in-store scanner and retail host back-end machine as a means ofdetecting, reading and processing the bill payment bar codes is but oneembodiment, and these components are not described herein aslimitations. For example, another method might utilize a personalcomputer, terminal, or other equipment having a bar code capablescanner, receipt printer and an interface to the data collection networkinterface in place of the in-store system. Ideally, such a computerwould have the same functionally equivalent interface as the in storesystem. In fact, it is contemplated that, as a transitional measure,until the retail stores modify or update their in-house check-outsoftware systems to accommodate the data collection network interface, asimple PC might operate in its place and serve as a model prototype todemonstrate the operational aspects of this system. Bar CodingValidation

Prior art systems have concentrated on the visual aspects of billremittance stub recognition, detection and validation against potentialfraud, typically using optical character recognition (OCR). The presentinvention applies a bar code solution to the general bill paymentsproblem, rather than a new variant or improved OCR technique. Bar codeis more efficient than OCR by several magnitudes because bar codes canbe detected reliably and processed by relatively simple hardware andfirmware, whereas OCR requires long physical scan times and significanthost CPU processing requirements for character recognition (and thenonly for a selected set of fonts). Bar code consists of binary elementsthat are parity checked for every bar code symbol and globally checkeddigited at the message level. OCR consists of many analog segments thathave to be neurally correlated and matched to the human readablecharacter set with no internal self-checking controls. In short, barcode is the future digital solution whereas OCR is a dated analogsolution that still plagues most bill payment processes today.

The Universal Product Code (UPC), printed on most retail products today,is a 12 digit number that is a concatenation of four numeric fields—aclassification number (1), a producer identification number (5), aproduct identification number (5), and a check digit (1). The need for astandards authority first arose in 1972 when the supermarket industrydecided to mark each of the grocery point-of-sale packages with a uniqueidentifier to speed checkout transactions, therein creating anorganization that today is called the Uniform Code Council (UCC). Theunderlying bar code symbology is merely a convenient representation ofthis UPC code format that can be reliably detected by simplepoint-of-sale scanning equipment (thus, it does not matter whichparticular bar code is used).

There is no standard way of representing multiple data fields in asingle scan line, given the designs and formats of various bar codestandards and conventions commonly in use today. For a typical billpayment application, two fields are minimally required—a 6-7 digitbiller identification and a variable length (up to 22 characters ormore) alphanumeric customer account number. If these fields wereconcatenated in a fixed format in a single bar code scan line on a billhead, it is very doubtful that low skilled retail help would reliablyscan the correct bar code where multiple bar codes might appear on agiven bill head. To perform error-free data validation on this scanline, more information must be embedded within the data itself.

In the retail environment where bar coded products abound, there is adistinct need to determine that a bar code, submitted for processing, iscorrect and valid for the target bill payment processing application.One cannot assume that the retailer will always submit a valid bar codefrom a bill remittance stub that may contain more than one printed barcode sequence. If, for example, a utility company prints the new billpayment bar code, in addition to an already existing internal routingbar code, the two bar codes must be disambiguated. While the utilitycompany can easily distinguish its own internal routing code by itsprinted position on the bill remittance stub, a retail cashier might notknow which to present. The solution is for the cashier to use trial anderror. If the first bar code attempted does not validate, the second (orthird, etc.) should be scanned. Validating a bar code bill payment“signature” in the course of the bill payment process is a component ofan embodiment of the present invention.

By using a unique bar code “signature” having multiple levels of datavalidation implemented by check digit algorithms, a bar code scanningsystem may reliably recognize and validate a valid bill payment barcode. The concept of paper envelopes may be used as an analogy forrelating the validation method of the invention. In the embodimentdescribed herein, three “envelopes” are used (although those skilled inthe art will recognize that any number of “envelopes” or levels ofvalidation may be used), the first being inside the second, and thesecond inside the third. At the outermost layer, the third “envelope”has printed, on the outside, the bill payment bar code “signature”. Ifthe bar code is detected and read correctly by the hardware scanner, theresulting alphanumeric information is valid in that it comparedcorrectly with the embedded encoded bar code check symbol. If this firstoperation is successful, the “envelope” is opened. The directionsprinted on the inner “envelope” specify to calculate a check digit onthe resulting alphanumeric information derived from the bar code,comparing the calculated result against the last digit in the string. Ifthis second operation is successful, the next “envelope” is opened. Theprinted directions on the innermost “envelope” specify to use the formatdesignator digit(s) to decode and to verify the data integrity of theembedded component data elements. Each of these data elements should beverified by calculating their check digits and by utilizing otherindependently available data validation checks.

If all three levels of validation successfully pass muster, then a validbill payment “signature” has been detected and the resulting data shouldthen be passed to the target bill payment application for subsequentprocessing. Failure at any intermediate validation level results in anegative acknowledgement. The prime purpose of this bar code “signature”design is to unconditionally identify the detected scanned bar code asbeing proprietary to the present invention, in the absence of any otherexternal information, through multiple layers of check digitinformation, format designator indicators and local data validationschemes.

A number of different application “signature” formats may be implementedwithin a bar code scan line as a series of successive embedded“signature” data fields. In one embodiment, each signature data fieldconsists of three elements: a format designator (“fd”) consisting of oneor more digits, a data field (“data”) consisting of one or more fixed orvariable length sub-data fields, and a check digit (“cd”) algorithmassociated with the format designator and the level at which it appears.

FIG. 6 illustrates a bar code “signature” 600 in one embodiment of theinvention, utilizing four levels of successive embedded “signature” datafields. The Level I data validation 601 is simply the hardware decode ofthe bar code symbology, using the embedded check symbol character asdata validation—i.e., all the bar code symbols were detected andprocessed correctly. Applicability of the data to the intended targetapplication is demonstrated when all the remaining levels of validationare successful. As shown in FIG. 6, Level 2 data validation 602 consistsof one signature data field (although it could have had more). The datavalidation of the Level 2 signature data field consists of twochecks—that the format designator value (for that level) is correct andthat the check digit calculation for the data string consisting of theformat designator digit(s) and the data field digits matches the checkdigit character. The Level 2 format designator defines at least threecharacteristics: the check digit algorithm implementations (in thisexample, 1), the number of data elements (in this example, 1), and thenumber of trailing discard characters for bar code odd/even countpadding (in this example, 2). The number of unique combinations of theabove three characteristics will determine the number of formatdesignator values required at this level. For this example, there isonly one check digit algorithm to disambiguate target applications,there is only one data field element, and there are two paddingcharacter combinations for the Code 128 bar code. Thus, the total numberof format designator values required at this level is two.

The Level 3 signature data field 603 checks operate on the residualLevel 2 data. The Level 3 data validation checks are similar to theLevel 2 checks and the format designator defines at least these threecharacteristics: the check digit algorithm implementations (in thisexample, 1), the number of data elements (in this example, one fixed,one variable or fixed), and the field lengths for one or more dataelements. As shown in FIG. 6, there are two data element fields. Thenumber of data splits defined for this data field would determine thenumber of format designator values that are required for this level.

The fourth 604 to nth 605 levels comprise a continuing iterative processof Level 3. Depending on the attributes or properties that onearbitrarily assigns to the data (and hierarchical functions) at eachlevel determines the number of format designator values required at thatlevel. The target application receives all the data fields from thefinal level of data validation.

A carefully chosen set of conventions for the format designators at eachlevel will facilitate correct data field parsing with the additionalsecurity that multiple levels of check digit validation will ensure dataintegrity and “positive ownership” to the target application. The formatdesignator digit(s) do not necessarily have to be leading as illustratedabove. An alternative format for the leading format designators could beas is illustrated in the bar code signature 700 of FIG. 7, in which thedata strings precede the format designator digits.

With reference to the exemplary embodiment shown in FIG. 6, a sampleformat of the unique bar code bill payment “signature” 800 is shown inFIG. 8, as a multiple layered data validation scheme. A bar codetypically consists of 6 sections: (1) a quiet zone (˜0.25″ of whitespace) before the bar code; (2) a unique bar code symbol that representsthe “START” character; (3) bar code symbols representing data characters(1300017350764058410363); (4) bar code check symbol that represents acalculate check digit of the preceding data character block; (5) aunique bar code symbol the represents the “STOP” character; and (6) aquiet zone (˜0.25″ of white space) after the bar code. If the hardwaredecode of this Level I envelope data string is not successful, theretail cashier should not get a good bar code scan confirmation. If thehardware decode is successful, the retailer cashier should get a goodbar code confirmation (but not necessarily of a valid product code). Agood hardware decode of a bar coded scan line is defined as thedetection of valid bar code symbols within the string that, whenprocessed through the defined check digit algorithm, matches theembedded string check symbol character. This is the first level of datavalidation check that must pass.

When the bar coded data characters are decoded from this scheme ofvariable width white and dark bar patterns, the result is the followingstring of (alpha)numeric characters: 1300017350764058410363. Calculatinga split modulus 10 check digit for the string to match against the lastcharacter, using a 1313 . . . mathematical weighting scheme, results inthe table of calculations illustrated in FIG. 9. The Level 2 formatdesignator value (1) is chosen to indicate the check digit algorithm(Split Modulus 10 with mathematical weights of 1313 . . . ), the numberof data field elements (1), and number of trailing padding characters(0) to utilize the high density Code 128 Type C symbol set. The Level 2format designator value (2) is chosen to indicate the check digitalgorithm (Split Modulus 10 with mathematical weights of 1313 . . . ),the number of data field elements (1), and number of trailing paddingcharacters (1) to utilize the high density Code 128 Type C symbol set.The modulus (or the remainder) of the resulting sum of the digits (87divided by 10) yields 7. The complement of the remainder 7 yields 3(10−7=3). This calculated result is the check digit of the above digitstring, and successfully matches the last digit in this illustrativeexample. This is the second level of data validation check that mustpass. If this validation is successful, the operation proceeds to theLevel 3 envelope data decode and validation algorithms.

In this particular example, there are only three levels of validationdefined. The Level 1 check is a hardware validation data check. TheLevel 2 check is a pre-qualifying software validation data check. TheLevel 3 check is an “ownership” data check (i.e. whether this is the“signature” for bill payment data under the present invention).Different “signatures” can be constructed for any number of applicationprogram uses through a judicious design scheme and the selection offormat designators. Format designators are arbitrary indicators withwhich to properly decode the format of and to validate the ensuing datastring—in this case, the format designator is placed as the first (oneor more) leading digit(s). At different levels, the same formatdesignator values can have different meanings

Turning now to FIGS. 10 and 11, two format designator values have beenchosen in this example (at Level 3) to encapsulate six format andvalidation data characteristics—all of which must be correct for thethird and final data validation check to pass. The Biller ID in each ofthese examples is “173” in a 6-digit numbering system. The embeddedspaces in the encoded data examples 1000 and 1100 of FIGS. 10 and 11 arenot significant and are inserted to show more clearly the various fieldswithin the example digit strings. The six format designatorcharacteristics shown in FIGS. 10 and 11 define either format (1,2,4,5)or data validation (1,2,3,6) checks. A format characteristic defines thelayout of the data whereas a validation characteristic facilitates datachecking. To validate a unique bar code application program “signature”,the more dependencies that exist within the data at each level forsubsequent cross checking and validation, the better. In theillustrations of FIGS. 10 and 11, there are two format designatorexamples with all possible variants within several constraints that arechecked and validated. Where there might be several different Level 2check digit algorithms employed, a Level 3 dependency is checked.Condition # 1 is checked against valid range of format designator valuesfor the current Level (in this case 3, 4). Biller Identification Number(in this example, 173) is determined if Condition #3 is TRUE and if itexists within the list of current and valid billers (an independenttable acquired by another means). Where the biller account number checkdigit algorithms are not known, a check digit is calculated and added tothe account number—to be checked then stripped when presented to thebiller (Format Designator Value=4). Where the biller account numbercheck digit algorithm is known, it is checked against biller definedspecifications (Format Designator Value=3): Conditions #1, #6. Withinthe Level 3 envelope for each of the above examples, the decoded andcheck digited values of the Biller Identification Number and thepresented Biller Customer Account Number results are as follows: ForFormat Designator Value=3, Biller ID=173, Customer Account=07640584103;and for Format Designator Value=4, Biller ID=173, CustomerAccount=0764058410. This is the third level of data validation checkthat must pass. If all the components in the Level 3 envelope test andcompare successfully, then the unique bar code bill payment “signature”has been correctly validated for further processing, and an indicationis given to the retailer or cashier that a dollar amount payment shouldbe entered for this item.

The primary purpose of this bar code “signature” design is tounconditionally identify the detected scanned bar code as beingproprietary to a system or method according to the present invention, inthe absence of any other external information, and to validate (usingmathematical formulae and/or independent table look-up methods, ifpossible) all the data element components therein.

The methods and procedures by which the format designator concept couldbe extended are strictly an implementation issue of design schemes andan adopted set of orthogonal convention(s). While the foregoingillustrative working example uses only three levels of “envelopes” tovalidate the unique bar code bill payment “signature”, more levels couldhave been used, as required. The format designators in the foregoingexample utilized a fixed data format with a set of predefined checkdigit algorithms for each level. Possible design extensions in furtherembodiments might include: (1) a format designator design scheme thatdefines a dynamic variable number of sub-field elements and/or a set ofdynamic component string lengths for each of the defined set of thesub-field elements (in contrast to the foregoing illustrated predefinedfixed schemes); (2) a format designator design scheme having more thanone digit in length, wherein each digit specifies an independent set ofpredefined orthogonal attributes that can be combined in a mix-and-matchfashion (e.g. a two digit format designator would specify a primary setof attributes in the tens digit that is qualified by a secondary set ofattributes in the units digit); and (3) format designator design schemeswherein subsequent trees of sub-field elements are controlled by one ormore preceding levels of format designators.

Bar Coding Specifications

The bill payment application bar code printed on each bill remittancestub might minimally consist of four basic fields, printed as a singlestring of digits: a format designator (1 digit); a biller identificationnumber with optional embedded check digit (7 digits); a customer accountnumber with optional embedded check digit (22 digits); and a check digitof the previous three fields (1 digit). Of course, those skilled in theart will recognize that the number of fields and/or digits per field asdescribed herein is specified by way of example, and not limitation, andthat the number and length of fields may vary according to eachembodiment of the invention. In this example, the outermost bar codeenvelope for this information conforms to documented ISO bar codingconvention standards, utilizing an embedded check digit algorithm toverify the integrity of the entire bar code scan line data. It isstrongly recommended that the biller defined customer account numberalso contain an embedded check digit, as a prudent secondary validationmeasure. If an embedded check digit does not already exist within thebiller customer account numbering scheme (or the biller does not wish todisclose that information as being company proprietary), an alternateaccount number format provides a temporary check digit that is checkedthen discarded before presentment to the biller. If the detected barcode scan line data correctly passes the triple tiered and multipleembedded check digit calculations, this mechanism will virtuallyguarantee “defect free” biller and customer account data. Otherwise, abill payment stub whose bar code has been mutilated or defaced by thecustomer is immediately rejected at the point-of-sale entry.

To accommodate future requirements, an expanded set of formatdesignators could define new data format structures or redefine thecharacteristics of current data fields. The following is a possible listof characteristics that a format designator element might define withina digit string: number of sub-field elements; component string lengthsof one or more of these subfield elements; check digit algorithms to beapplied to each of the sub-field elements; odd/even string packingfactors when a single bar code character represents one or more digits(Code 128 is a good example of this compression feature); or subsequenttrees of dependent sub-field elements. These format changes would betransparent to the end user. The bar code data, detected by the retailcheckout scanner, is passed directly to the data collection networkinterface unit for secondary validation and translation. The parsed“translated” form of this data is then passed back to the back-end hostprocessor system for completing the bill payment transaction at thecheckout counter.

The bar code might either be printed vertically on the left (bottom totop) or right (top to bottom) hand side of the bill remittance stub withsufficient surrounding white space to satisfy the criteria of the ISObar code format. If there are other proprietary bar codes present on thebill remittance stub, the checkout counter cashier could have the optionof folding or bending the bill remittance stub such that only therequired bar code is visible for a successful bar code scan of the billpayment information. Vertically printed bar codes of the formatdesignator, biller identification number and the customer account numberon most bill remittance stubs is good for a combined number sequence of14-25 digits at the lowest common denominator bar code print resolution(nominal bar code “X” dimension ˜0.010 inches and total bar code stringlength S 3.0 inches). For sequences longer than that, it is recommendedthat the bar code sequence be printed in a manner parallel to thehorizontal OCR line such that extraneous proprietary bar codeinformation can be folded out of the way for a successful scan.

The assigned biller identification number is acquired or distributedfrom a central registry authority, akin to the manner in which theUniform Code Council assigns new producer identification numbers. As faras the customer account number is concerned, it is recommended that thebiller include a check digit within the account numbering scheme. Whileit is unlikely that a customer account number would be read in error ifthe hardware bar code check symbol scan validates, this additional checkdigit provides double assurance to the biller that the customer accountnumber is correct. This is especially important from the biller's pointof view when accepting bill payments from many sources of ACH submitteddata, many of which may be human entered from the myriad of home bankingsoftware packages available—known empirically to have very high humaninput error rates.

To this point, it has been tacitly assumed that the biller will want toprint this new bar code on the face of his bill remittance stub.However, technical, as well as political, reasons could preclude theprinting of a new bar code standard on the face of the current billremittance stub. An alternative option might be for the new bar codeformat to be printed on the back of the current bill remittance stub (soas not to disturb the current mode of visual remittance processing) orprinted on a second or subsequent tear-off bill page, formatted for thatspecific purpose. A further alternative would be to utilize a speciallyprinted bar code format enclosure page (printed on better and sturdierpaper stock) that would permit multiple reuse by the customer. Sparespace on that enclosure could even be sold for advertising to defray theprinting costs by the biller.

The most common point-of-sale bar code used throughout the retailindustry is the UPC-A variant. However, most scanners employ an internalfirmware auto-recognition mechanism that permits them to detect and toread several bar code symbologies. The bar code symbology, under currentconsideration for the most general specification of an alphanumericcustomer account number, is the Code 128 family. Where there are onlynumerics, the Code 128 Type C variant features a high-density barcode—one printed symbol per two digits of information. During thecheckout aisle scanner process, the back-end host processor recognizes abar code data scan line as a valid bill payment transaction and requiresthe cashier to enter an amount to be paid. When this amount is entered,a fixed transaction fee is added to the bill payment amount. On theprinted customer receipt, the bill payment is recorded in a form similarto the following, including biller name and account number, amount paid,transaction ill, date and time, and transaction fee charged:

PMNT: Biller Name

ACCT: Customer Account Number

AMNT: $ ddd.cc

TRID: rrrrrrr yjjj ssss

DATE: mm/dd/yy hh:mm

FEE: $ dd.cc

This time-stamped transaction data is then stored in the datacommunication network interface unit for later transmission to thetransaction collection system.

Where the checkout scanner detects multiple bar codes, the retailercashier can be trained to recognize the placement of a valid billpayment “signature” bar code to be scanned for the proper processing ofa customer payment. Scanning any other bar code, present on the billremittance stub, that does not pass all of the bill payment “signature”tests results in an immediate validation reject by the datacommunication network interface unit.

Back-end Host Processor

The retailer back room host processor may be required to support twowell-defined interfaces, the front-end checkout counter scanner systemand the back-end data collection network interface. When the Code 128bar code format is encountered from bill remittance stubs, it should berecognized as a customer bill payment, rather than the UPC code for acustomer selected product. This decision can be performed in a number ofways by the back-end host processor. The easiest logic path to implementwithin the back-end host processor is as follows: if this bar code scanis not recognized as one of several defined pre-programmed sequences,pass it to the data collection network interface before rejecting thescanned data completely. The back-end host processor passes the completescan line data to the data collection network interface unit forsecondary level validation and data translation. If secondary levelvalidation is successful, the parsed translated data is passed back tothe back-end host processor to complete the processing for this billpayment transaction. In this case, the returned translated data consistsof the Biller Name, the Customer Account Number, and Transaction ID thatis printed on the customer printed receipt.

As bill payment data is processed by the front-end checkout scannersystem and completed, it may be relayed by the back-end host processorto the data collection network interface unit to be stored innon-volatile memory for later transmission to the central transactioncollection system. There are a number of standard data collectionnetwork interface functions that may be accessed by the back-end hostprocessor system, e.g. validating the biller name, adding a transaction,voiding a transaction, printing daily or weekly processed totals andreports, and setting or reading operational configuration parameters.

Data Collection Network Interface (DCNI) Unit

The retailer on-site data collection network interface unit shouldprovide a well-documented, protocol neutral features and functionsfront-end interface to the retailer back-end host processor. The DCNIshould also provide a non-volatile memory storage capability ofaccumulated customer bill payment data. This may be accomplished with asolid state hardware design that is electrically isolated at all thecritical interfaces and has no moving elements that mechanically wearand eventually cause the unit to fail. The back-end of the datacollection network interface should provide a transparent interface tothe central site transaction collection system and include functionalitysuch as: (1) performing secure validation procedures with thetransaction collection system; (2) downloading DCNI unit operatingsystem and program application code firmware; (3) downloading DCNI unitoperational configuration parameters; (4) uploading DCNI unit memoryimage (emergency and debug use); (5) downloading Verification Biller IDand Name data; (6) uploading transaction data (compressed & encrypted);and (7) setting DCNI unit system date or time. The primary function ofthe data collection network interface unit is to provide a set ofsupport functions to the retailer host processor to aid in thecollection, validation and storage of transaction data from customerbill remittance stubs scanned at the checkout counter.

FIGS. 12 and 13 illustrate the mainline transaction informationinterchange between the checkout scanner, retailer host processor, andDCNI unit in processing a bar coded customer bill remittance stub, inone embodiment of the invention. As shown in FIG. 12, the interactionoccurring in the case of a valid account number begins with the bar codebeing read 1201 by the checkout scanner and passed to the retailer hostprocessor. The host processor next validates the bar code 1202 andpasses the resulting data to the DCNI!. Since the account number isvalid, an acknowledgment of validity (ACK) is returned 1203 via the hostprocessor to the checkout scanner, along with the biller name andaccount number. The amount to be paid is queried 1204 at the checkoutscanner, and the amount entered is passed 1205 to the retailer hostprocessor, which passes 1206 the bar code data and the amount entered tothe DCNI, where this transaction data is stored 1207. If the data storeis successful, an acknowledgment is sent 1208 via the host processor tothe checkout scanner, along with a transaction ID number. The checkoutscanner may then print 1209 the biller name, account number, andtransaction ID as a transaction receipt. As shown in FIG. 13, in thecase of an invalid account number, the checkout scanner first reads thebar code 1301 and passes it to the retailer host processor. The hostprocessor next validates the bar code 1302 and passes the resulting datato the DCN!. Since some aspect of the data passed to the DCNI isinvalid, an acknowledgment of invalidity (NAK) is returned 1303 to thehost processor with a reason code. The Reject Payment status, passed tothe checkout scanner 1304 from the host processor, mayor may not containthe DCNI reject reason code for human feedback. Reason codes mightinclude, e.g., invalid scan line (not a valid bill payment “signature”scan line), Biller ID check digit error, invalid Biller ID (old billerthat is not serviced anymore), or Biller Customer Account Number checkdigit error. Payment is consequently rejected at the checkout scanner1304.

In one embodiment, the Transaction ID that is returned to the retailerback-end host processor, as a positive confirmation that the transactiondata has been accepted and successfully stored, is a 15 digit numberconsisting of: DCNI unit identification (7 digits), last digit of year(1 digit), Julian date (3 digits), and transaction sequence number (4digits). This information may be printed on the customer receipt asthree groups of digits (7,4,4) as an ease-of-use issue, should it benecessary for the consumer to dictate his Transaction ID to a customerservice representative over the telephone.

Periodically throughout the day (primarily based on time and transactionvolume thresholds), the DCNI unit should transmit its stored data to thetransaction collection system after it has aged past the “transactionvoid” window. The “transaction void” window is defined as the time pastwhich the transaction cannot be canceled after it is taken (e.g. 15minutes to eliminate the possibility of fraud). In one embodiment, thedata elements of each transaction transmitted to the host consist of thefollowing: Retailer ill, Biller ill, Biller Account Number, Amount Paid,Sequence Number, Transaction Date/Time Stamp, Status as Active or Void,and Operator ill. When these transactions are transmitted to thetransaction collection system, they may be sent in batches whose batchname conforms to the following naming convention: DCNI unitidentification (7 digits), last digit of year (1 digit), Julian date (3digits), and last transaction sequence number in batch (4 digits). Sucha numbering convention makes it easier for customer service operationspersonnel to trace a given Transaction ill.

The design and implementation of the data communication networkinterface functions could optionally be performed as a real time on-linesystem or as a batch oriented system to the transaction collectionsystem. If implemented as a real-time system, communication costs to thecentral site and a redundant “hot cutover” central site hardwareconfiguration is very expensive, by comparison, to eliminate all singlepoint equipment failures in an overall system operation. A central sitebatch oriented “hot backup” system eliminates the real-time aspect oftransaction processing that exponentially escalates costs. Central siteredundant hardware still has to be available, but much less of it isrequired to achieve the same level of system operation reliability.

In systems that are explicitly designed for real-time operation (e.g.credit card verification), “hot cutover” systems contain elements thathave to be designed, a priori, into the combination of system andapplication software to anticipate and to detect the many types ofpotential system, application or equipment failures. When detected,transaction processing is immediately and automatically transferred toan operational system “in waiting”. In the ensuing recovery modeprecipitated by this equipment switch over, transactions, in transit atthe time of the first system failure, are either pushed through tocompletion (if past a defined system bottleneck check point) or arepulled back. If a transaction is pulled back, all database recordmodifications are restored and then the transaction is reprocessed fromground zero. “Hot backup” designed systems have fewer constraints. Spareequipment is powered up and ready to be switched into operational mode.While time is important, it is not as critical in this situation. In oneembodiment, the DCNI unit resubmits transaction batches, not explicitlyacknowledged as processed, at a later time (ranging from minutes tohours). Subsequently, if duplicate transactions are encountered onresubmission, they are not processed but are acknowledged as such to theDCNI unit. Much less premeditated contingency system software isrequired in this environment for robust system operation.

Transaction Collection System

While the data collection network interface may be a single unit, thecentral site transaction collection system may consist of multiplecentral processor server units acting in concert to perform a collectiveset of functions and processes. This design approach permits scalableprocessing and avoids the possibility of single point failures thatmight curtail or impact the production processing of incomingtransaction batches.

FIG. 14 illustrates one possible configuration for the transactioncollection system 1400. In the embodiment shown, incoming encrypted datafiles from the field data collection network interface units would comethrough a dial-up network or modem bank 1401 over a TI or similarconnection 1402 into an entry router 1403 outside the central sitefirewall, via a channel service unit/data service unit 1404 (CSUIDSU) orother similar device for providing isolation between the network and theon-premises equipment. Parallel firewall machines 1405, one operating in“hot back up” mode, filter the inbound data traffic from validated andsecure data sources. In addition to their primary security role, one ofthe ancillary functions of the firewalls 1405 is to load balance thedata traffic across all available file transfer protocol (FTP) engines1407. A plurality of FTP engines 1407 are shown in the diagram as beingin a scalable multi server configuration, coupled via one or moreintegration hubs (e.g. 100 MB or 1 GB Ethernet hubs) 1425. The FTPengines 1407 provide the raw computing power to transfer data packetsfrom the firewalls 1405, to coalesce the data packets into data filesand to write them to the FTP storage server 1408, which may compriseRAID (redundant array of inexpensive disk) storage or similar massstorage.

In the FTP storage machine 1408, a monitor process scans for completedinbound files to process. Upon finding such a file, the file decryptionkeys are fetched from the central transaction collection server 1410 andthe file name is packaged in a message packet that is sent to one of aplurality of transaction processor (TP) engines 1409 in a scalablemulti-server configuration, coupled via one or more integration hubs1425. It is noted that the transaction processor engines 1409 and FTPengines 1407 may optionally be provided with a console switching unit1460 for sharing a single console (e.g. monitor, mouse, keyboard) acrossthe plurality of engines 1407, 1409. A transaction processor engine 1409(TPE), upon receiving this message packet, then has sufficientinformation available to locate, to decompress and to decrypt theinbound data file into its component data record types. The variousreceived data record types are stored in a database (e.g. StructuredQuery Language, or SQL) on the transaction collection server 1410. Thetransaction collection server 1410 database is configured across severalpartitioned sets of physical hardware 1411 set up for RAID storageoperation. The primary purpose for spreading the databases over severalpieces of physical and logical hardware and/or software is to avoidhaving single points of data congestion and equipment failure. Thetransaction collection server 1410 database is the destination for allthe data collected at all the retail processing locations. On ascheduled production basis, the data is aggregated and sorted, accordingto the biller identification associated with each transaction customeraccount number. ACH transaction files are prepared and formatted bybiller identification, which then maps into biller-designateddestination ABA bank routing and bank account numbers.

The administrative/data reporting server 1420 provides access to a copyof the production data for back office operations and monitoring by oneor more work stations 1427, without burdening the front end collectionsystem. In the embodiment shown, the “glue” that holds the whole networktogether is one or more 100 MB or 1 GB Ethernet hubs 1425. Thistechnology provides the foundation cornerstone by which various elementsof the network communicate with each other and access each other's massstorage as local devices. The web/fax server 1430 provides on-demandreports to retailers through a web server application. It also providesperiodic reports to retailers that can be faxed out through the normalpublic telephone network 1445. The electronic transmission interface(ETI) machine 1440 prepares the data that has been accumulated andprocessed by the transaction collection server 1410 for transmission tothe Federal Reserve ACH Network. It formats the data into the correctACH CIE (customer initiated entry) format and transmits this data fileto the appropriate destination bank interface. An optical drive 1432,tape storage unit 1433, or other such storage means may be provided forcreating removable backups, which may be stored off-site.

In the CIE Entry Detail Record format, the following exemplary fieldsare populated with bill payment information: AMOUNT (Field 6) ispopulated with the Customer Payment; INDIVIDUAL NAME (Field 7) ispopulated with the Transaction Sequence Number (which contains theJulian date of payment); INDIVIDUAL IDENTIFICATION NUMBER (Field 8) ispopulated with the Biller Customer Account Number; and DISCRETIONARYDATA (Field 9) is populated with the Payment Complete Time encoded as atwo digit time field ranging from 00 to 95. This number may be dividedby 4 to calculate military hours (decimal) to the nearest quarter hour.For example, the number 26 divided by 4 would yield 6.5 (0630 or 6:30AM). The remaining fields in the CIE Record format are populated withmandatory banking information data, such as biller ABA and accountnumber.

A print control station 1470 is coupled to one or more print engines1471 for handling printer transmissions to one or more laser printers1472 for a variety of report and other printing functions.

FIG. 15 illustrates an exemplary transaction processor executivecontroller (TPEC) display screen 1500, in one embodiment of theinvention. The TPEC monitor program resides in the FTP storage server1408 and is responsible for detecting complete inbound data files fromthe field retailer based data communication network interface units.When an inbound data file is detected, TPEC fetches the file decryptionkey from a master database and then dispatches it and the data file nameto one of the transaction processor engine (TPE) 1409 program threads.The TPE 1409 decompresses and decrypts the inbound data file and storesthe component plain text data records in the SQL database that resideswithin the transaction collection server 1410 on RAID storage 1411. Asshown, display screen 1500 may include features such as jobs attempted1501 (i.e. batches received) and transactions processed 1502 (i.e.individual data records processed from the batches received). Thisdisplay 1500 shows the current Transaction Process Engine(s) batch jobstatistics for the system batch dated 10112/2000 at 13:44:31. As shown,TPEC is in Paused State—it is not currently dispatching any detectedinbound data files to the TPE engines 1409. For this batch, 129 inbounddata files were processed that resulted in 244 data records, stored inthe SQL database.

FIG. 16 illustrates an exemplary system monitor station (SMS) displayscreen 1600, in one embodiment of the invention. This display 1600 showsthat individual retailers may be configured in a directory tree-likestructure, with each of a plurality of distributors 1601 being a parentto one or more retailer bill pay sites 1602. The directory framework ofretailers 1602 may conform to any convenient form of administrativestructure, e.g. a distributor model, based on a hierarchy of people, ora physical model, based on territories with defined boundaries (states,counties, or towns). Also illustrated in this display is the placementof INSTRUCTION files 1603 that can reside at any level within anarbitrary configuration structure. An INSTRUCTION file 1603 containsoperational directives to be applied to retailer terminals at or belowthe level of placement in the directory structure (i.e. transactionpricing, unit transmission schedule, revised configuration parameters).

FIG. 17 illustrates an exemplary end of batch monitor (EBM) displayscreen 1700, in one embodiment of the invention. When the current systembatch is closed out, this display 1700 shows the status of the variousdata processing phases (e.g. system batch 1701) that take place when thecollection of received transaction data batches from the retail datacommunication network interface units are consolidated and sorted bybiller for electronic transmission. EBM may be a Visual Basic programthat orchestrates the series of Structured Query Language (SQL) scriptsand ancillary programs to perform transaction consolidation, generalsystem batch reporting, database trimming and data archiving.

FIG. 18 illustrates an exemplary electronic transmission interface (ETI)display screen 1800, in one embodiment of the invention. This display1800 includes a summary 1801 of the dollar amounts sent to each of theelectronically connected remittance partners. The batch status window1802 shows the current status of the transmission batches (QUEUED,ACTIVE, DELETED, or COMPLETED). An additional column (not shown) may beincluded to show the confirmed time of transmission completion.

FIG. 19 illustrates an exemplary ETI transaction detail display screen1900, in one embodiment of the invention. For a specific partner (in theexample shown, MasterCard RPS), this display shows the details for eachremitted transaction—biller name 1901, originating source transactiondetail for direct traceability 1902, customer account number 1903 andamount paid 1904. From an electronic perspective, the biller is onlyinterested in the payment amounts to be applied to various customeraccount numbers.

FIG. 20 illustrates an exemplary ETI map biller-to-partner displayscreen 2000, in one embodiment of the invention. For each biller definedin the system, there is a one-to-one mapping of electronic destinations.While ninety-five percent or more billers may have their remittancesdelivered via the Federal Reserve ACH network, the remainder of theremittances may be delivered by a combination of directly connectedlinks and secondary consolidator links. Display screen 2000 shows, foreach biller, a Biller ID 2001 and Biller Name 2002 mapped to aparticular electronic destination 2003. Not explicitly demonstrated bythis display is the implicit dynamic mapping of internal Biller IDs 2001to external Merchant IDs (depending on the electronic link utilized)that has to take place for this system to interoperate successfully witha variety of external electronic networks. Different electronic linksmay also have different data formats, as those skilled in the art willappreciate.

FIG. 21 illustrates an exemplary transaction browser display screen2100, in one embodiment of the invention. For every transactionprocessed through the collection system, the transaction browser programaccesses and displays all the relevant information pertaining to thattransaction, either locally or through a secure Web Server Applicationaccess to remote billers. Such information may include, e.g., aselection entry portion 2101, check and trail record 2102, and paymentrecord 2103. (It should be noted that the bill image would typically notbe transmitted to the transaction collection system, and that it isshown in this figure for illustrative purposes only.) The system derivesthe biller account number from the proposed standard format of billerimprinted bar codes, as described herein.

In summary, the primary function of the central site transactioncollection system 1400 is to collect transaction data from the retailnetwork, sort and aggregate the data by biller, and to remit thecustomer payment data and the money to the biller by the Federal ReserveACH Network. In the same way that customer data is collected, processedand credited to individual billers, the ACH Network is used toelectronically debit the retailers for the payments that they havecollected from their customers. The transaction fee, paid by thecustomer, may be shared by the retailer and the transaction processor.

Central Biller Registry System

The current state of the bill payment industry is very fragmented, andmany billers currently print their own customer invoices to suit theneeds of their own remittance processing systems. There is no universalinvoice printing standard to which everyone adheres because there is noeconomic motivation to do so. Several primary items are required for abar coded customer bill payment system to succeed: (1) an industrystandard that is relatively simple to implement with little or nomarginal cost; and (2) a sufficiently large network of retailestablishments, induced by the economic incentives of taking billpayments with little or no marginal cost; and (3) a method of deliveringtotally error-free, electronically remitted customer payment data andfunds to billers at no charge.

From a business point of view, there are several organizations that,once persuaded, might provide the required motivation momentum in eachof these areas. With this assumption in hand, a central registry systemwould be required to collect information and to assign the bar codebiller identification numbers, in the same manner that Network Solutionsassigns domestic Internet addresses for the World Wide Web or theUniform Code Council assigns UPC codes for the retail industry.

In one embodiment, assigned biller bar code identification numbers maybe 7 digits in length. The first 6 digits identify the biller (in amaximum population of 1 million) with the 7th digit being the checkdigit. For every biller bar code identification assigned, the followinginformation might be required for central collection: (1) Biller Name,Address, Phone Number, Fax Number; (2) Biller Administrative ContactName, Phone Number, E-Mail Address; (3) Biller Remittance Contact Name,Phone Number, E-Mail Address; (4); Electronic Connection Type (ACH orDirect); (5) Bank Name, Address, Remit Account Information, Type; (6)Bank Contact Name, Phone Number, E-Mail Address; (7) Account NumberInformation—detailed account format specifications. Having collected theforegoing information, a biller bar code identification number would beassigned and a set of bar code print specifications sent to the billercontact. It would then be the responsibility of the biller to print andto remit a set of test bill remittance stubs for conformance testing andvalidation. Conformance testing on the set of sample bill remittancestubs would ensure that the bar code image quality and physical bar codedimensions satisfied the lowest common denominator bar code scanners atretail. Validation testing would ensure that information, supplied bythe biller, regarding the printed bar coded customer ‘account numberconformed to published account number validation specifications.

Payment Time Stamp via Federal Reserve ACH Network

The INDIVIDUAL NAME field (Field 7) in the ACH CIE Batch Detail Recordcontains the customer payment transaction number, which is composed ofthe following 4 data fields: DCNI unit identification (7 digits), lastdigit of year (1 digit), Julian Date (3 digits), and the transactionsequence number (4 digits). While the DCNI unit number identifies theretailer where the customer payment was taken, the next four digitsspecify the year and the Julian date of payment submission andcompletion. The DISCRETIONARY DATA (Field 9) in the ACH CIE Batch DetailRecord may be populated with the Payment Complete Time encoded as a twodigit time field ranging from 00 to 95. As stated above, this number maybe divided by 4 to calculate military hours (decimal) to the nearestquarter hour. For example, the number 26 divided by 4 would yield 6.5(0630 or 6:30 AM). Time synchronization may be acquired from universaltime standards available through the Internet or national dial-up timeservices (US. Naval Observatory, Washington, D.C. or the NationalInstitute of Standards and Technology, Boulder, Colo.).

Whether or not sanctioned by a governmental agency, such as the US. PostOffice, this time stamp could be recognized in much the same way thatthe US. Post Office postmark on letters is used to prove on-timesubmission. The customer would have printed proof of payment date andtime, by virtue of his store receipt, that a biller could notartificially manipulate for purposes of assessing penalty payments. Thebiller would also have electronic access to this field as well.Currently, the biller has no automated means by which to read the US.Post Office postmark for proof of on-time bill payment submission (noris there any incentive to do so). Bill payment “due date” as specifiedin the small print of every credit contract can have a variety ofindividual definitions, none of which is directly visible to ortraceable later by the customer. A universal bill payment time stampwould eliminate all the variability of these “due date” definitions ifthe biller recognized this time stamp as the creditor date of receipt asspecified in the Federal Reserve Regulation Z Section 226.10.

The advantage of this date stamping mechanism to the customer is that itwould give him marginally more time to remit his bill payment on time tothe biller. In the extreme, the customer could pay his bill payment at alate-hours store at one minute to midnight on the due date. The customerwould no longer have to worry about remittance delivery times. Theadvantage of this date stamping mechanism to the biller is thatextremely late payments may be electronically credited to the biller nolater than 36 hours after customer payment. In the majority of cases inwhich the biller had multiple daily data feeds from his bank, the creditwould probably issue in fewer than 24 hours. Electronically deliveredand electronically applied, the current level of biller effort in thehandling of late payments would be entirely eliminated with this systemin place. In the extreme case, billers could safely invoke 48-hourcut-off notices with little or no error of service call recalls.

Electronically remitting data and money through the Federal Reserve ACHNetwork only works for those billers whose customer account numbers areless than or equal to 22 digits which is the current maximum width ofField 8, INDIVIDUAL IDENTIFICATION NUMBER, using the standard CIE EntryDetail Record format. If a remitted customer account number is longerthan 22 characters, then either one of two possible solutions isavailable: using Field 3, 80 columns of data in the CIE Addenda Recordformat; or implementing a dedicated data link to the biller with abiller specific data format.

Alternative Electronic Networks to Accommodate Special Billers

For high volume billers preferring to have their data delivered to themfaster than the current Federal Reserve ACH Network delivery schedule,direct file transfer links (e.g. FTP) from the ETI machine through theInternet may be made available. File data formats and the particulardelivery mechanisms may be tailored to meet any biller requirement, solong as it expedites the flow of customer payment information. In thismode of operation, biller data would be available for processing withinminutes after the scheduled transaction collection system production“system roll” completes. The “system roll” sorts and aggregates billerdata on a daily production schedule—once every 12 hours. Payment totalsfor these transaction batches would be delivered via the ACH Network.For a trusted remitter, it is not necessary to directly couple thetransaction dollars with the transaction data. The time lag betweentransaction data and transaction dollars via the Federal Reserve ACHNetwork should be no more than 24 hours.

Improved Payment Embodiments

The embodiments described hereinabove relate, generally, to bar codebased biller/payor systems for electronic bill payment. As describedhereinabove, it is contemplated that, in an exemplary electronic billpayment infrastructure (e.g., see reference numeral 500 of FIG. 5)consistent with the invention, consumers can pay their bills atsupermarkets and large retail chain stores and receive immediate creditfrom billers for their payments. In such an infrastructure, the billerreceives good payment funds, deposited directly into his bank account,and error-free electronic payment data for consumer bill payments by 6AM the very next business day. Contractually, the biller backdates thereceived bill payments to the “electronic postmark” time and date paidat retail, regardless of the time that the payment data takes to post tothe biller's accounts receivable system. Compared to the present paperbased remittance processes commonly employed throughout the paymentsindustry today, such an infrastructure provides for an electronicprocess that remits error-free payment funds and data directly tobillers within hours, rather than days.

As efficient as this electronic bill payment process may be, it may notbe fast enough for the needs of Internet commerce based companies,selling products to electronically connected remote consumers. Theelectronic bill payment process, as described hereinabove with respectto billers and payors, still depends on the biller generating a paperbar coded invoice statement and sending it to the consumer by US Mail, aprocess that can take, on average, anywhere between 6-8 days. When theconsumer has the financial resources in hand to pay his bill, he canthen remit his payment directly to the biller, electronically, withinhours.

In an improvement to the electronic infrastructure for this process,described in this section, Internet commerce-based companies can nowchoose a new bill payment method that is very simple and can reduce thetime interval between biller invoice statement generation and consumerpayment notification to the biller, to less an hour.

Another improvement to the electronic infrastructure for this process,described in this section, is the provision for person-to-person moneytransfers. Currently, there are several organizations that offerelectronic person-to-person money transfers as long as the sending andreceiving parties deposit and receive their remitted funds within thesame organizational network of geographically dispersed branch offices.What may be a convenient remittance location for the sender may not beso for the receiver and/or vice versa. Person-to-person money transferscan be easily accomplished with a bar coded deposit slip that permits asender to remit funds directly into a receiver's bank account, and suchfunds are subsequently accessible for withdrawal at a nearby andconvenient Automated Teller Machine (ATM) or for a debit card purchase.The details of these improvements are discussed herein below:

Improved Electronic Bill Payment Network

The embodiments described in this section relate to an improved nationalelectronic bill payment network, wherein bar coded invoice statementsare generated immediately by the biller or the consumer and remitted tothe consumer in the span of seconds to minutes via facsimile, e-mail orother image transmission method. Upon receipt of such an imaged invoicestatement, the consumer, with payment in hand, may go to a local storethat accepts and processes these bill payments. When the consumerpayment is processed at retail, it is electronically remitted to thebiller with absolute accuracy within 24 hours after receipt of payment,and electronic notification to the biller may occur within minutes afterreceipt of payment, with no payment repudiation.

Such an electronic bill payment network offers the following benefits:The biller benefits by receiving 100 percent accurate electronic billpayment information and good funds, delivered into his bank account by 6AM the very next business day that can be directly applied to hisaccounts receivable. The biller benefits by receiving an immediateelectronic notification of consumer payment at retail with funds thatcannot later be retracted. As a result, billers can then ship theconsumer product sooner, thereby raising consumer satisfaction levelswith their Internet portal. The consumer benefits by receiving animmediate electronically delivered bar coded invoice statement for hisInternet shopping basket of products via facsimile, e-mail or otherimage transmission method. The consumer benefits because he can then payhis bar coded invoice statement locally with his choice of cash, check,debit card or any credit card for his Internet shopping basket withouthaving to disclose any personal financial information to a remoteInternet store. Further, local payment precludes the possibility offuture fraud resulting from hackers' or others' unlawful access to anystored financial information left and residing at remote Internetstores. The local retail establishment benefits by receiving arelatively cost-free margin from each payment transaction taken.Finally, it is anticipated that a national enhanced network with manyretail outlets will spur the demand for yet new immediate andelectronically delivered financial products and services, using“signature” specific bar codes, and thus, may generally benefit theeconomy of the country or other geographic area in which it isimplemented.

An exemplary embodiment of the improved bar coded bill payment basedsystem consistent with the present invention utilizes a bar code on thebiller invoice, which is delivered to the customer electronically, i.e.,by fax, e-mail, or, other image transmission method, and paymentinformation and payment credits are returned to the billerelectronically. This system may augment some elements of thebiller/payor network 500 (described hereinabove with respect to FIG. 5)with faster and parallel processing elements. In this case, the billeraccounts receivable and US Mail consumer remittance mechanisms may beenhanced with a new accounts receivable invoice statement imagegeneration mechanism that can be activated, on demand, either by abiller customer service representative or by a consumer initiatedaction. The result of either action is a bar coded invoice statementimage that is electronically remitted to the consumer within a timeframe of seconds to minutes. The transaction collection system describedhereinabove, which already has an inherent user Internet accessibletransaction browser capability, may be enhanced with e-mail, facsimileor other means of electronic notification to the biller whenspecifically designated payments have been received. An automated callerresponse system may provide for consumer inquiry confirmation ofpayments.

Turning now to FIG. 22, an exemplary improved electronic bill paymentnetwork 2200 is illustrated. For all the goods and services rendered toa consumer over a given traditional billing period (or interactiveInternet shopping session), the biller accounts receivable 2202 mayaccumulate a dollar total and generate a detailed bar coded invoicestatement image 2203 that can be electronically remitted to the consumer2204. This same process can also be used by a biller customer servicerepresentative 2201 to replicate a previous invoice statement that aconsumer may have lost. For example, if a consumer wants an immediatereplacement copy of the invoice for payment, the consumer can access abiller web site to generate a remittance or deposit document. The timefor a consumer to request the electronic invoice statement 2203 may beas little as a few minutes after a request is made. The invoice 2203 istransmitted to the consumer 2204, which transmission may be from a fewseconds to several minutes, depending on factors such as the method oftransmission, queue capacity, and number of open queue slots. Theconsumer 2204 receives the bar coded invoice statement image 2203.

To pay the bill, the consumer 2203 might go to a local store (or otherlocation with appropriate hardware/software/network connection) thatprocesses these bill payments. The time for this to occur is variable,depending upon the consumer's circumstances, and may occur in as littleas a few minutes. The consumer 2203 presents his imaged bar codedinvoice statement 2203 to the checkout cashier for scanning by thecheckout scanner 2205, which may be done while other retail UPC codeditems are being scanned. Instead of looking up an in-house UPC code forpricing, the scanner 2205 would pick up the bill payment bar code thatidentifies the biller to be paid and the account number to be credited.The consumer tells the checkout cashier the amount to be paid on thataccount and his option for requesting “normal” or “express” paymentprocessing, and the cashier inputs the amount to be paid into a terminal(which may be integrated into a point-of-sale system) which is incommunication with a backend host processing system 2206. The checkoutof remaining products and items (or bills) continues until the completetotal for all goods and services is calculated. Upon receiving paymentfrom the consumer, that bill payment is then complete. The consumer mayreceive a printed receipt of the payment tendered with the date and timethe payment was made. The in-store backend host processing system 2206immediately completes and forwards all the payment data to the datacollection network interface unit 2207, which may occur in a little as afew seconds.

The data collection network interface 2207 (DCNI) unit collects andstores all the consumer bill payment data in non-volatile memory.Periodically (e.g., throughout the day, and/or based on time andtransaction volume thresholds), the DCNI 2207 transmits the bill paymentdata to the central site transaction collection system 2211, which ispart of a central site computer system 2210 that may also include anInternet server/browser 2212 and/or automatic caller response system2213. Additional transmissions may be scheduled before the dailytransaction collection system J211 aggregation times. If a particularconsumer payment is designated for “express” processing, it mayimmediately be transmitted to the central site computer system 2210 whenthe transaction void window expires for that payment. The time for theback-end and collection system processing has no impact on customerpayment time, since all payments may be time-stamped. Separatelycalculated calendar day payment counts and totals may also be sent tothe transaction collection system 2211 as an independent transactionaudit balancing mechanism.

The transaction collection system 2211 may continuously (and/orperiodically) receive payment data information from a distributednetwork comprising a plurality of data collection network interfaceunits 2207 deployed at field retail establishments. Before the lastprocessing window closes at the Federal Reserve Automated Clearing House(ACH) Network 2214, all customer payments may be sorted and aggregatedfor direct remission to their respective billers, which may takeapproximately an hour.

As the transaction collection system 2211 receives payment datainformation from the network of data collection network interface units2207, it processes and stores each consumer bill payment into adatabase. Once stored in the database, that payment and ancillaryinformation can be viewed with a local transaction browser or Internetweb site display 2212. When “express” payments are encountered in thepayment data stream, immediate electronic notification may be posted tothe biller in one of several possible forms: e-mail, facsimile or billerspecified custom electronic form. Accessible from that same databaseinformation, an automated caller response system 2213 can verballyconfirm the receipt of a particular transaction, particularly forcustomers 2209 seeking “comfort call” confirmation regarding the statusof a payment. For “normal” payments, the biller customer servicetoll-free number may be nominally printed on the consumer receipt. For“express” payments, the biller customer service toll-free number may bereplaced with a special in-house toll-free number to relieve billercustomer service representatives 2208 of nervous consumer confirmationinquiry calls, typically for payments that are long overdue.

Processing and distribution of electronic payment data may be done usingthe Federal Reserve Automated Clearing House (ACH) Network 2214, whichmay take 6-9 hours. At the biller's bank 2215, the electronic paymentdata may be received from the ACH Network 2214 and stripped andreformatted according to biller specified formats, which may take 4-6hours. Finally, the biller's accounts receivable 2202 and/or customerservice computer files may be updated. Depending on the “legacy factor”of the biller's computer processing systems, this process can rangeanywhere from 2-3 hours to 4-5 days.

From both the biller's and consumer's perspective, the paymentnetwork/system 2200 described in this section may be contrasted with thebiller-payor network/system 500 (described hereinabove with reference toFIGS. 5 et seq.), as follows:

From the biller perspective, both networks 500, 2200 may be capable ofdelivering good payment funds and data directly into the biller's bankaccount by 6 AM the next business day after the consumer pays his billat retail. The improved network 2200 may deliver electronic notificationof consumer payment information to the biller within minutes after thepayment is made at retail with the “express” delivery service. Allpayment funds collected can remain safe and secure within the FederalReserve banking system network at all times. Moreover, the improvednetwork 2200 can deliver a consumer invoice electronically andimmediately, assuming the biller can generate and remit an electronicinvoice statement image 2203 and the consumer has a corresponding deviceor means with which to receive the electronic biller invoice statementimage (email, facsimile etc.). With this enhanced network 2200, thebiller, having Internet access and using his choice of standard Internetbrowsers, can confirm a consumer's payment by querying the database ofprocessed transactions in the transaction collection system 2211 with avariety of database selection keys and criteria. Further, the biller canreceive full payment funds for the amount stated on the bar codedinvoice statement 2203. This point is especially important when it comesto paying various governmental and state license, permit and tax fees.By statute, many states and governmental organizations cannot accept thepayment of license, permit and tax fees from consumers using eithercredit or debit cards because of the subsequent discounted paymentsremitted. Third-party payment surcharges, directly assessed from theconsumer over and above the due payment amount, are generallyacceptable. For example, the Commonwealth of Massachusetts has 307different types of license, permit and tax fees that must be paid byconsumers either by check or cash.

From the consumer perspective, the consumer can have a choice of localpayment method (e.g., cash, check, debit card or any credit card), whenpaying a bar coded invoice statement 2203 at retail. The consumer doesnot have to divulge any personal financial information to a remoteInternet storefront that electronically generates and delivers bar codedinvoice statements directly to a consumer. With this enhanced network2200, the consumer can subsequently confirm the electronic receipt ofhis processed payment at retail from an automatic caller response system2213. Further, with this enhanced network 2200, the consumer, havingInternet access and using his choice of standard Internet browsers, canconfirm his own payment by querying the database of processedtransactions in the transaction collection system 2211 with a specifictransaction identification number.

Presently for Internet commerce based companies, there is no mechanismavailable for conducting a purely “cash” sale over the Internet, whereconsumer cash and retail product can be exchanged in one anonymousatomic transaction. Currently, problems abound with all other forms ofpresent payment methods, as follows:

Payment method fees always erode the profit margin of any retail orInternet storefront. Credit and debit card companies charge retailmerchants varying commissions, based on a variety of factors that canrange upwards from 2% of the purchase price. By law, these merchantscannot charge consumers different prices for the same retail productwhether paid for with cash or by credit. Check guarantee companiesimpose processing charges on every consumer check passed through theirservice. Third party “e-wallet” payment type companies also charge fortheir value-added services as well. Therefore, the merchant absorbsthese various discounts from his profit margin as a normal “cost ofdoing business”. Checks, if exchanged, take time to clear and can be“stop paid” at the whim of the consumer. No one is exposed in thissituation if the seller chooses to wait out the prescribed checkclearing time (on average, approximately 4-5 days); however, ultimateconsumer satisfaction will be impacted by this delay. Credit cardtransactions require the consumer to divulge personal financialinformation to the remote Internet seller, which leaves open thepotential for future and untraceable fraud. Then, that credit cardtransaction can be disputed and repudiated by the consumer, up to 60days later, leaving the seller with an un-collectable debt. While debitcard transactions cannot be repudiated, they also require the consumerto divulge personal financial information to the remote Internet seller,again, leaving open the potential for future and untraceable fraud. Theconsumer generally has no guaranteed recourse to recover any stolenfunds debited from his account. Third party “e-wallet” payment typecompanies that require consumers to register their bank account numbersfor secured transaction payments over the Internet are ripe forlarge-scale fraud. The consumer generally has no guaranteed recourse torecover any stolen funds debited from his E-Wallet. The enhancedelectronic bill payment network 2200 consistent with the presentinvention permits remote buyers and sellers to perform anonymous “cash”sale transactions, using the Federal Reserve banking system as thetrusted escrow agent to safely and securely transfer funds betweenbuyers and sellers.

An advantageous feature of this enhanced bill payment network, with astandardized bar coded bill payment “signature” featured as itscenterpiece remittance mechanism, is that all the non-deterministic timedelays have been removed from the total bill payment cycle. In legacybill pay arrangements, the two largest delay factors are the billerinvoice paper statement preparation, printing, mailing systems and theUS Post Office mail delivery system. With the present invention, theconsumer can now exercise a larger control function over his billpayment remittance process. The consumer can request an immediateinvoice statement, which only requires minutes to formulate and todeliver electronically. The consumer has his choice of payment methodsat a trusted local retail establishment and receives a printed billpayment receipt confirmation, guaranteed by the biller. The consumerpayment method to the biller is completely anonymous, in terms ofdivulged personal financial information. Subsequently, the consumer, aswell as the biller, can verify that the bill payment has been receivedand processed at the central payment distribution site. Thereafter,payment funds and information may be electronically remitted to thebiller within hours, by 6 AM the following business day directly intothe biller's bank account.

It should be recognized by those skilled in the art that, although theforegoing description refers to a bar code transmitted bye-mail or byfacsimile, other methods of transmission are possible and are includedin the invention, e.g., facsimile transmission to or from a computer,facsimile machine, e-mail, file transfer protocol (FTP), hypertextmarkup language (HTML), extended markup language (XML), hypertexttransport protocol (HTTP), modem, the Internet, a wide-area network(WAN), a local-area network (LAN), diskette, or other removable storagemedium.

Money Transfer Embodiments

In the above descriptions of an exemplary electronic bill paymentnetwork 500 (described hereinabove with reference to FIGS. 5 et seq.),references have been made regarding the extensibility of this networkand its internal structure to provide for new, cost-effective financialproducts and services. Domestic and international person-to-person moneytransfer services is one such product described here. (Of course, themoney transfer technology described in this section may also haveapplicability to business-to-person, person-to-business,business-to-business, or other types of money transfers.)

The current forms of domestic and international money transfer servicesoffered today are very labor intensive for both the person sending themoney as well as the service provider. The amount of paperwork that hasto be filled out by the sender and then manually transcribed into a“communication system” by the service provider has been the ostensiblejustification to the customer of the high fee structure to provide thisservice. In point of fact, this service is extremely profitable, whichis aptly demonstrated by the fact that there are so many large and smallmoney transfer service providers in this industry, primarily servingimmigrant communities whose members regularly send money to their homecountry families. Some service providers, such as Western Union, userelatively “high tech” electronic communication services to transferfunds while other small service providers use “low tech” courierservices to physically transport funds to their intended destination.

Currently, there are several organizations that sell domestic orinternational electronic person-to-person money transfers as long as thesending and receiving parties deposit and pick up the remitted fundswithin the same organizational network of geographically dispersedbranch offices. Fees for this service can range upwards from $35 pertransfer. However, convenient remittance locations for the local sendermay not have corresponding convenient delivery locations for the remotereceiver, or vice-versa.

In a system consistent with the present invention, domesticperson-to-person money transfers can be easily accomplished with a barcoded deposit slip that permits a remote sender to remit funds directlyinto a receiver's bank checking account, providing funds that aresubsequently accessible at a convenient local automated teller machine(ATM) or for a debit card purchase.

Future international (e.g., Mexican) person-to-person money transferscan be coordinated with appropriate financial organizations or banksthat commonly distribute a form of debit card to their customer base.These organizations would distribute to their customer base plastic barcoded deposit-only cards keyed directly to their debit card, which maythen be sent to a remitter in another country (e.g., the United States).Using that bar coded plastic deposit-only card instead of a bar codedbank deposit slip would affect a deposit of the funds directly into thedebit card account corresponding to the deposit-only card. In this way,domestic and international money transfers could cost far less than thefees charged today for this equivalent service.

The complete details of a bar coded bill payment “signature” aredescribed hereinabove in the section entitled “Bar Coding Validation”with respect to FIGS. 10 and 11, wherein a structure of successive dataenvelopes of embedded “signature” data fields are employed, consistingof a series of format designators, data and check digits. In theexamples of FIGS. 10 and 11, which illustrate two arbitrary formatdesignator values, the customer account number consisted of one numericfield whose associated check digit was the trailing digit of either adivulged format (=3) or an unknown format (=4) to which the billerappended a check digit according to a specified algorithm. In bothcases, there is an independent mechanism in place to mathematicallycheck the validity of the customer account number.

In the person-to-person electronic money transfer embodiment describedin this section, the retail based electronic bill payment infrastructureis utilized, with the modification that the biller identification numberis now used to identify the destination payment network instead of adestination biller organization. In the U.S. banking system, thestandard bank account numbering scheme is based on a two-part numbersystem consisting of an ABA (American Banking Association) number (8digits plus a check digit), uniquely identifying the U.S. bankinstitution, and a local account numbering convention within thatbanking institution. While the format designator=4 validation templatescheme can reliably be used to implement a generalized person-to-bankaccount remittance mechanism within the structure of the electronic billpayments infrastructure, the definition of a new format designatorvalidation template would offer several advantages: An additionalcustomer account number validation step further reduces data errors.Within the full customer specified account number, the ABA portion ofthe account number can be independently verified. The billeridentification number would be reduced from 6 to 2 digits, inrecognition of the fact that there are many fewer bank based or moneytransfer payment networks than billers. With a reduced number string,shorter bar code strings fit more appropriately on small banking depositslips that measure, on average, 6″ wide by 3″ high.

FIG. 23 illustrates an exemplary specification for the new formatdesignator=5 format. As shown, the bar code 2300 comprises a I-digitformat designator value=5; the number of components (2 fixed length(3,9), I variable length) by definition; 2-digit payment networkidentification number; I check digit of preceding 2 digits using 37weights, MOD1O algorithm; 8-digit ABA number (51066065); 1 check digitof preceding 8 digits using 37137137 weights, MOD1O algorithm; entirecustomer bank account number (5106606550766936692) using 1212 . . .weights, split MOD10 with added check digit to be discarded beforepresentment to the destination payment network (4); and calculated checkdigit of level 3 envelope using 2121 . . . weights, split MOD10algorithm (4).

As illustrated in FIG. 24, this bar code 2401 appearing on a bankdeposit slip 2400 (or, alternatively, printed on a plastic or papercard, or printed on other media, e.g., debit card, credit card, bankcard, affinity card, card bearing a magnetic stripe, identificationcard, smart card, or card bearing at least one name corresponding to anaccount number encoded in said bar code) could be presented at a retailcheckout aisle, equipped for bill payment transactions, to initiatedomestic person-to-person money transfers. By 6 AM the followingbusiness day, the money remitted the previous day may be available tothe recipient to withdraw from a local ATM machine or to make paymentfrom a debit card keyed or associated with that account. The ATM ordebit card PIN (personal identification number) provides the same levelof access security to the receiver of these person-to-person moneytransfers as exists for local funds that already reside in the account.

To implement an international (i.e., any-person-to-any-person electronicmoney transfer) using the retail based electronic bill paymentinfrastructure, the biller identification number may be used to uniquelyidentify the target destination payment network. In the case of aforeign payment network based on a system of debit card accounts, theformat designator=4 validation template scheme can reliably be used toimplement and validate any generalized account numbering scheme to remitfunds. A new format designator validation template definition offersextended customer account number verification advantages only if thedestination payment network is willing to divulge its mathematical orother method of customer account numbering validation scheme.

In a hypothetical exemplary scenario consistent with the invention, anational chain of retail gas stations/convenience supermarket storescalled GasoMax is located throughout the whole of Mexico, serving thepublic at large. GasoMax issues PIN protected debit cards to all theircustomers, in effect, setting up a pseudo-bank account for each of them.Instead of carrying cash, these customers deposit or apply money tothese accounts so that they can later purchase food staples orconvenience items at the same time they come for fuel. When GasoMaxissues these PIN-protected debit cards to their customer base, one ormore bar coded deposit only cards are included (and/or a bar code mightbe printed on the debit card itself). The debit card can either be usedto deposit local money into their account or to withdraw money in theform of purchases at the national chain GasoMax gas stations. FIG. 25illustrates an exemplary GasoMax debit card 2500, which resembles astandard debit card. FIG. 26 illustrates an exemplary deposit-only card2600 comprising a bar code 2601 consistent with the invention. In thisexemplary scenario, the bar coded deposit-only card 2600 (or,alternatively, a bar code printed on the standard debit card) would beused in U.S. retail stores that offer access to the electronic billpayment network. Whereas most customers submit their U.S. based billerbar coded invoice statements to the cashier for payment, the customerthat presents the GasoMax bar coded deposit-only card 2600 is making apayment to a destination payment network (Payment Network=51, using astandard Format Designator=4 description). Payments remitted to thispayment network are automatically converted to local currency by GasoMaxat a better rate than the larger commercial money transferorganizations. Commercial money transfer companies charge up to $25 per$300 remittance as a foreign exchange (FX) fee on top of the base $35remittance fee. In the recent past, wire transfer companies have beensanctioned for these usurious currency exchange practices. GasoMax wouldhave a greater incentive to offer a better exchange rate to its customerbase for its money transfer services than the current crop of commercialmoney transfer services. GasoMax could expand its local customer base toshop for goods and services through its chain of gas stationsupermarkets that also offers a convenient money transfer service, as anaffinity draw or loyalty program, for relatives working outside of thecountry to support their loved ones in Mexico.

Several further examples of “real-life” scenarios demonstrating theutility of an improved payment network consistent with the invention areprovided, as follows:

EXAMPLE I Payment for Mobile Telephone Service

A client procures a mobile phone Subscription from a well-known nationalvendor. The client gives his place of employment as his cell phonebilling address. As a new customer, he is assigned a total credit limitand an accrued monthly limit. When this client subsequently leaves hisplace of employment, he forgets about changing his mobile phone billingaddress and continues to use his mobile phone regularly, until one dayhis mobile phone stops working. When he calls the customer serviceoffice to inquire about the matter, he finds out that his mobile phoneusage is well within his credit limits but that the reason for hismobile phone being disconnected is that bill payment is overdue by tendays. The company does not accept credit card payments and only acceptsa check payment for the total past due amount. The company restores hisservice ten days after receiving and processing his check.

With an enhanced bill payment network consistent with the invention inplace, this client could have remitted his late payment with the“express” payment service, as described hereinabove. The mobile phonecompany would have been electronically notified minutes after his retailpayment, so that his cell phone service could be restored within anhour, rather than days.

EXAMPLE 2 Payment for Internet-Based Auction

The business model for the Internet-based auction (e.g., eBay) is verybasic in concept, a meeting place for bringing together Internet buyersand sellers, wherein an electronic framework displays sellers' goods andservices. When a sale is completed between a seller and a buyer, theonline auction house charges a sales commission. It is theresponsibility of the seller and the buyer to establish a lowest commondenominator payment exchange method. Individuals selling items, aregenerally not equipped to process Mastercard or VISA credit or debitcards. If the seller accepts a personal check payment from the buyer,shipment of the sold item is delayed until the buyer check clears. Abuyer can mitigate a seller shipment delay if he is willing to go outand purchase a money order to send to the seller. If the buyer andseller wish to use a third party payment clearinghouse, (e.g., Billpointor PayPal), then both must register personal financial information abouttheir respective bank accounts to transfer money, as well as pay yetanother sales commission charge. In general, none of these paymentalternatives are particularly attractive if a buyer or seller desiresany degree of financial confidentiality.

With an electronic payment network consistent with the invention inplace, an online auction house could provide a cost-effective andvalue-added anonymous payment alternative within its framework ofauction services. When a sale is completed, the online auction houseprovides the means for the buyer to print out a bar coded invoicestatement, citing the online auction house as the biller of record witha transaction identification number. Instead of purchasing a moneyorder, which would then have to be physically remitted, the buyer thenpays this invoice at a local supermarket. When the online auction housereceives the electronic payment the very next business day, it notifiesthe seller of the completed payment via e-mail and then sends a checkfor that payment amount to the seller. Aside from exchanging theirmailing addresses, both buyer and seller maintain their financialprivacy.

This same sales paradigm would also work well for home shoppingtelevision channel environments, (e.g., Home Shopping Network, QVC),wherein the “express” payment option could be used when buyer desire isat its highest level.

EXAMPLE 3 Automobile Insurance Payment

Insurance companies have varying grace periods within which to pay theirinsurance premiums, beyond which the policy is irrevocably canceled. Ifone cannot or chooses not to pay the entire annual premium on itsanniversary date, an installment plan of smaller payments mayalternatively be offered. If a premium payment is not received, acancellation notice is sent toward the end of the payment grace periodspecifying a “hard” cancellation date. If a policy is canceled due tonon-payment, depending on the prior payment history, the insurancecarrier may not want to reissue another insurance policy because of aprevious poor payment record. Therefore, given the gravity of thepossible consequences, time is of the essence when it comes to payinginsurance premiums on time—whether for car insurance, home insurance orpersonal life insurance. Mailed late payments may not be delivered andprocessed in time. Depending on company policy, even in-person paymentsdirectly to insurance agents, during normal business hours, mayor maynot be acceptable. A confirmed electronic payment made using an enhancedbill payment network consistent with the invention would provide a wayfor both the insurance company and insureds to know precisely whenpremiums are paid.

EXAMPLE 4 Payment to College Student

When a parent agrees to send money for college expenses to a child awayat school, a question that typically arises is, “how fast do you needthe money?” A printed bar coded bill payment “signature” on out-of-townbank checking account deposit slips would enable remote deposits with asimple cash, check, debit card or any credit card payment at a localsupermarket. A college-bound child could have previously sent home anample supply of these deposit slips to cover for such eventualities. Ifa supply of originals is not available, a facsimile copy (sent at highresolution mode) will generally perform the job equally well. Fundsdeposited with this payment mechanism are electronically available thevery next morning for withdrawal from a local ATM cash dispensingmachine. For a small fee (e.g., about a dollar), this service is muchfaster, more convenient to all parties involved and cost-effective thanany existing person-to-person money transfer service.

Further Alternate Embodiments

The present invention may use the public Internet and Internetcompatible HTTP and UDP protocols for the network interconnectionsdescribed herein, as well as the Federal Reserve Automated ClearingHouse (ACH) Network or other networks. Those skilled in the art willrecognize that the servers and their various components, as well as anyother components described herein may be implemented in software,hardware, or a combination of both, and may be separate components or beintegrated into other components described above. Likewise, theprocesses described herein may be separate or combined and may run oncommon, shared, or separate machines, and as integrated or separatesoftware modules.

Additionally, scanning bar codes, in methods consistent with theinvention, may be performed using, e.g., wand or handheld scanningdevices, scanning devices mounted to or near a point of sale system, andother such scanning devices, and such devices may be devices coupled toother devices, e.g., a computer, cash register, or point of sale system,or alternatively, integrated therein. A scanning device consistent withthe invention may alternatively be coupled to or integrated into a PDA,handheld or pocket computer, as well as a mobile telephone or otherportable, wireless, or computerized device. Thus, it is contemplatedthat an account corresponding to a mobile telephone or other suchdevice, or other credit or debit account corresponding to the user ofsuch a device, could be automatically debited for payment to a payee, inmethods consistent with the invention.

It will be appreciated by those skilled in the art that, although thefunctional components of the above described embodiments of the systemof the present invention are embodied as one or more distributedcomputer program processes, data structures, dictionaries or otherstored data on one or more conventional general purpose computers (e.g.IBM-compatible, Apple Macintosh, and/or RISC microprocessor-basedcomputers), mainframes, minicomputers, conventional telecommunications(e.g. modem, DSL, satellite and/or ISDN communications), memory storagemeans (e.g. RAM, ROM) and storage devices (e.g. computer-readablememory, disk array, direct access storage) networked together byconventional network hardware and software (e.g. LANIW AN networkbackbone systems and/or Internet), other types of computers and networkresources may be used without departing from the present invention.

The invention as described herein may be embodied in one or morecomputers residing on one or more server systems, and input/outputaccess to the invention may comprise appropriate hardware and software(e.g. personal and/or mainframe computers provisioned with Internet widearea network communications hardware and software (e.g. CQI-based, FTP,Netscape Navigator or Microsoft Internet Explorer HTML Internet browsersoftware, and/or direct real-time TCP/IP interfaces accessing real-timeTCP/IP sockets) for permitting human users to send and receive data, orto allow unattended execution of various operations of the invention, inreal-time and/or batch-type transactions and/or at user-selectableintervals. Likewise, it is contemplated that the above-described serversconsistent with the present invention may be remote Internet basedservers accessible through conventional communications channels (e.g.conventional telecommunications, broadband communications, wirelesscommunications) using conventional browser software (e.g. NetscapeNavigator or Microsoft Internet Explorer), and that the presentinvention should be appropriately adapted to include such communicationfunctionality. Additionally, those skilled in the art will recognizethat the various components of the system of the present invention canbe remote from one another, and may further comprise appropriatecommunications hardware/software and/or LANIW AN hardware and/orsoftware to accomplish the functionality herein described.Alternatively, a system consistent with the present invention mayoperate completely within a single machine, e.g. a mainframe computer,and not as part of a network.

Moreover, each of the functional components of the present invention maybe embodied as one or more distributed computer program processesrunning on one or more conventional general purpose computers networkedtogether by conventional networking hardware and software. Each of thesefunctional components may be embodied by running distributed computerprogram processes (e.g., generated using “full-scale” relationaldatabase engines such as IBM DB2, Microsoft SQL Server™, Sybase SQLServer™, or Oracle 8.0 database managers, and/or a JDBC interface tolink to such databases) on networked computer systems (e.g. comprisingmainframe and/or symmetrically or massively parallel computing systemssuch as the IBM SB2 or HP 9000 computer systems) including appropriatemass storage, networking, and other hardware and software for permittingthese functional components to achieve the stated function. Thesecomputer systems may be geographically distributed and connectedtogether via appropriate wide and local-area network hardware andsoftware.

Primary elements of the invention may be server-based and may reside onhardware supporting an operating system such as Microsoft Windows NT12000 or UNIX. Clients may include computers with windowed ornon-windowed operating systems, e.g., a PC that supports AppleMacintosh™, Microsoft Windows 9S/98INTIME/2000™, or MS-DOS™, a UNIXMotif workstation platform, a Palm™, Windows CE-based or other handheldcomputer, a network- or web-enabled mobile telephone or similar device,or any other computer capable of TCP/IP or other network basedinteraction. The communications media described herein (generallyreferred to using the generic term “network”) may be a wired or wirelessnetwork, or a combination thereof.

Alternatively, the aforesaid functional components may be embodied by aplurality of separate computer processes (e.g. generated via dBase™,Xbase™, MS Access™ or other “flat file” type database management systemsor products) running on IBM-type, Intel Pentium™ or RISCmicroprocessor-based personal computers networked together viaconventional networking hardware and software and including such otheradditional conventional hardware and software as is necessary to permitthese functional components to achieve the stated functionalities. Inthis alternative configuration, since such personal computers typicallyare unable to run full-scale relational database engines of the typespresented above, a non-relational flat file “table” may be included inat least one of the networked personal computers to represent at leastportions of data stored by a system consistent with the presentinvention. These personal computers may run, e.g., Unix, MicrosoftWindows NT1200™ or Windows 95/98IME™ operating system. The aforesaidfunctional components of a system consistent with the present inventionmay also comprise a combination of the above two configurations (e.g. bycomputer program processes running on a combination of personalcomputers, RISC systems, mainframes, symmetric or parallel computersystems, and/or other appropriate hardware and software, networkedtogether via appropriate wide- and local-area network hardware andsoftware).

As those in the art will recognize, possible embodiments of theinvention may include one- or two-way data encryption and/or digitalcertification for data being input and output, to provide security todata during transfer. Further embodiments may comprise security means inthe including one or more of the following: password or PIN numberprotection, use of a semiconductor, magnetic or other physical keydevice, biometric methods (including fingerprint, nailbed, palm, iris,or retina scanning, handwriting analysis, handprint recognition, voicerecognition, or facial imaging), or other security measures known in theart. Such security measures may be implemented in one or more processesof the invention.

Source code may be written in an object-oriented or non-object-orientedprogramming language using relational or flat-file databases and mayinclude the use of other programming languages, e.g., C++, Java, HTML,Perl, UNIX shell scripting, assembly language, Fortran, Pascal, VisualBasic, and QuickBasic. It is noted that the screen displays illustratedherein at FIGS. 15-21 are provided by way of example only, and are notto be construed as limiting the invention or any component thereof tothe exemplary embodiments illustrated therein.

Furthermore, it is contemplated that the system and method describedherein may be implemented as part of a business method, wherein paymentis received from users, which might include customers, retailers, and/orbillers employing the invention. Such users may pay for the use of theinvention based on the number of files, messages, bills, or other unitsof data sent or received or processed, based on bandwidth used, on aperiodic (weekly, monthly, yearly) or per-use basis, or in a number ofother ways consistent with the invention, as will be appreciated bythose skilled in the art.

Those skilled in the art will recognize that the present invention maybe implemented in hardware, software, or a combination of hardware andsoftware. Finally, it should also be appreciated from the outset thatone or more of the functional components may alternatively beconstructed out of custom, dedicated electronic hardware and/orsoftware, without departing from the present invention. Thus, thepresent invention is intended to cover all such alternatives,modifications, and equivalents as may be included within the spirit andbroad scope of the invention as defined only by the hereinafter appendedclaims.

What is claimed is:
 1. A method of processing a financial transactionfrom a second party payer to a third party payee at a point of salelocation of a first party retailer, the method comprising: the thirdparty payee creating a bar code comprising discrete encoded data fieldsorganized into a plurality of validation levels comprising an outervalidation level and one or more inner validation levels, each of thediscrete encoded data fields comprising one or more of either a fielddesignator, a check digit value and/or a data string, the data stringcomprising either an inner validation level and/or payment information,the payment information comprising the identity of the payee and theidentity of the payer, and the encoded data fields configured to beinterpreted pursuant to a design scheme comprising a decoding method, avalidation method and a processing method, (i) the decoding methodcomprising decoding the bar code to yield a series of data values foruse in the validation method and the processing method, (ii) thevalidation method comprising determining whether the bar codecorresponds to a first type of financial transaction as opposed to asecond type of financial transaction that cannot be processed, and (iii)the processing method comprising processing the financial transaction topay the third party payee; the second party bringing an invoice havingthe third-party-created bar code thereon to the first party retailer;scanning the bar code and detecting the discrete encoded data fields andvalidation levels; decoding the discrete encoded data fields andvalidation levels yielding a series of data values used in applying thedesign scheme, validating the bar code to limit the carrying out of thefinancial transaction to the first type of financial transaction thatcan be processed pursuant to the design scheme, validating the bar codecomprising, with respect to each of the one or more inner validationlevels: (i) confirming that any format designator and/or check digitvalue within the data string of the inner validation level conforms tothe design scheme, (ii) rejecting the bar code as being associated withthe second type of financial transaction if any format designator and/orcheck digit value within the data string does not conform to the designscheme, (iii) identifying any such data string that does represent aninner validation level, and repeating steps (i), (ii) and (iii) for eachsuch inner validation level; and processing the bar code of the firsttype of financial transaction, processing comprising (i) identifyingeach data string that does not represent an inner validation level andidentifying the data values therein used in carrying out the financialtransaction, (ii) the second party payer paying an agreed-upon amount offunds to the first party retailer at the point of sale location; and(iii) directing a transfer of funds from the first party retailer to thethird party payee.
 2. The method of claim 1, the first type of financialtransaction corresponding to a plurality of sets of bar codes in whicheach set of bar codes comprises a distinct design scheme.
 3. The methodof claim 1, further comprising the first party retailer providing areceipt to the second party payer to document the transaction byidentifying details of the financial transaction.
 4. The method of claim1, further comprising alerting the third party payee that the funds willbe or have been transferred.
 5. The method of claim 1, where the invoicecomprises a digital image transmitted electronically.
 6. The method ofclaim 1, where the agreed-upon amount of funds paid are the same as theamount of funds transferred from the first party retailer to the thirdparty payee.
 7. The method of claim 1, where validating and decodingtake place at the same time.